Skip to main content
Veriqa’s sign-in is cross-device by design: the initiator shows a QR code and the confirmation happens on the phone. That makes the range of surfaces a sign-in can start from wider than usual — the initiator only has to display a code and wait for the outcome.

​
What works today

Where the device has a browser or a webview, surfaces differ only in how the initiator learns that it finished: the flow itself is the same authorize → code → token. Where it has none, the application’s backend creates a confirmation and exchanges it for the user’s id_token — see Smart TV and keyboard-free surfaces. A device with no backend of its own has no path yet: a full implementation of device flow is in progress.

​
Surfaces with no convenient input

This is where being cross-device pays off most. On a TV, a set-top box or a kiosk, typing a password means picking letters with a remote; a QR code plus a confirmation on the phone removes the problem entirely. Two things help on such surfaces:
  • live status — the /hubs/auth SignalR hub, with GET /api/transaction/{id}/status where WebSockets are unavailable;
  • initiator context — the confirmation message shows the person what they are confirming. On a kiosk or a shared device that matters more than on a personal laptop: see Initiator context.
The phone can also confirm with a Google or Apple account instead of a messaging app: the person signs in to that account on the phone and types nothing on the TV or the kiosk. This is a runnable sample, not a built-in channel — see Sign in with a Google or Apple account, confirmed on the phone.

​
When the initiator is a shared device

An office kiosk, a terminal in a hall, a screen by the entrance: the device is shared, but the person confirming is one particular individual. Two things are worth keeping in mind. A transaction belongs to a session, not to a device. The single-use cookie between callback and authorize is bound to the latest load of the sign-in page: if the page reloaded, the confirmation belongs to a different transaction and Veriqa returns browser_nonce_mismatch. That is protection against confirming someone else’s session — details in Troubleshooting. The QR on display is a secret for the length of the transaction. On a shared surface it is worth shortening the sign-in screen’s lifetime and not leaving the code up after it completes. On a shared device people often would rather not type their own passwords at all. Someone with no messaging app on their phone can confirm with their Google or Apple account instead: the provider’s password stays on the phone, and the shared device only shows the QR code — see Sign in with a Google or Apple account, confirmed on the phone.

​
Place as part of the scenario

Binding a sign-in to a physical place (a QR on a printer or on a dedicated office screen) is covered in the Place and identity scenario.

​
What does not depend on the surface

  • the set of confirmation channels — that is about the user’s phone, not about the initiator;
  • the claims and their contents;
  • the client requirement for a browser sign-in: a confidential client with a secret, or a public client with PKCE S256. The server-to-server entry is for a confidential client only.