DeviceBindingApi
final class DeviceBindingApi
Binds this device to the current user and later proves the device still holds that binding.
The device key pair is kept in the Keychain; the server stores the public key per binding.
Get an instance with AppIntegrityModuleApi.getDeviceBindingApi(clientConfiguration:username:password:restPath:).
-
Register this device using the scanned QR payload.
Expected QR shape:
unblu-bind://<host>/<account>?token=<t>&v=1(onlytokenis inspected; the rest is host-app-defined).Flow:
- Parse the token out of the QR payload.
- Generate (or reuse) the device key pair, return public key base64.
- Ask the server (via JS) for an enrollment challenge.
- Sign the decoded challenge locally.
- Send the signature back to the server (via JS) and receive the
bindingId.
Declaration
Swift
func registerWithQrPayload(qrPayload: String, completion: @escaping (Result<String, DeviceBindingError>) -> Void) -
Registers the current device using a raw enrollment
token(thetokenvalue of the QR payload) — for when the user types or pastes the code manually instead of scanning. Same flow asregisterWithQrPayload(qrPayload:completion:)without theunblu-bind://…URI parsing.Declaration
Swift
func registerWithToken(token: String, completion: @escaping (Result<String, DeviceBindingError>) -> Void) -
The bindingId persisted on this device, or
nilif there’s no binding for this app (never enrolled, or revoked, or local data cleared). Reads from the Keychain — no network or JS round-trip. Pair this withverify(bindingId:)to silently re-confirm a binding on startup.Declaration
Swift
var localBindingId: String? { get } -
The session cookies (name -> value) obtained for the device-binding REST calls, or
nilif no server call has completed yet (or the bridge isn’t REST-backed). After enrollment/verify you can reuse these to authenticate the WebView (e.g. by mapping them toUnbluCookies and assigningUnbluClient.customCookies) so it doesn’t have to log in again.Declaration
Swift
var sessionCookies: [String : String]? { get } -
The device identifier the server assigned during login (the value of the
…-devicecookie), ornilif no server call has completed yet (or the bridge isn’t REST-backed). The server creates aDeviceInfofor this id at login, and the device binding is anchored to it.Declaration
Swift
var deviceId: String? { get } -
The session obtained during the device-binding login as
UnbluCookies — the same set the binding calls used, including the…-devicecookie carryingdeviceId. Returnsnilif no server call has completed yet. Assign directly toUnbluClient.customCookiesso the WebView reuses the session (and the device id) without logging in again:if let cookies = deviceBinding.sessionUnbluCookies { client.customCookies = cookies }Declaration
Swift
var sessionUnbluCookies: Set<UnbluCookie>? { get } -
Confirms that this device still controls an existing binding.
Asks the server for a fresh challenge for
bindingId, signs it locally with the device’s private key, and sends the signature back for the server to verify against the public key it stored at registration. This proves liveness without re-enrolling.Declaration
Swift
func verify(bindingId: String, completion: @escaping (Result<Void, DeviceBindingError>) -> Void)Parameters
bindingIdThe binding to verify (as returned by
registerWithQrPayload/registerWithToken). Empty fails with.bindingNotFound.completion.success(())if the server accepts the signature. Common failures:.signingFailed(local key unavailable),.signatureRejected(server refused the signature), or a transport/login error surfaced as.bridgeUnavailable. -
Asks the server to revoke the binding; on success, clears the local key pair and the persisted bindingId.
Declaration
Swift
func revoke(bindingId: String, completion: @escaping (Result<Void, DeviceBindingError>) -> Void)