Back end
In the back end, the number of steps increases somewhat (see the diagrams below). This is due to a few additional back-and-forth exchanges of secret encoded messages among all the servers. These exchanges ensure that the person who initiated the process by clicking the Login button on the client website or app is still the same person at the end of the process, with none of the exchanges viewed or intercepted by eavesdroppers.
Back end flows¶
As with the front end, there are two flows depending on whether the client is a mobile app or a website on the desktop. They appear quite different in the following two diagrams, but the core steps are essentially the same:
-
The end user clicks the login button on the client mobile app or desktop site.
-
The client sends a PKCE code_challenge and a scope request to the Unbox auth server's
authorize
endpoint. -
The
authorize
endpoint sends a login_code_to_sign back to the client.-
Client mobile app case: The direct send is all that happens.
-
Client desktop site case: In addition to the direct send,
authorize
also redirects the client site to an auth page. This page displays a QR code with the login_code_to_sign embedded in it so that the end user can scan it with their mobile device.
-
-
The client passes the login_code_to_sign to the XYZ mobile app (to be signed once the end user consents to the scope the client requests).
-
Mobile client app case: The client sends the login_code_to_sign to XYZ directly (or takes the end user to their mobile app store to download XYZ first).
-
Client desktop site case: The client sends the login_code_to_sign to XYZ by first embedding it in a QR code, then getting the end user to scan it with their mobile device. This either launches XYZ directly, or sends the user to their mobile app store to download XYZ first.
-
-
XYZ asks the end user to consent to the scope request.
-
The user consents to the requested scope of access. Once consent is provided, XYZ uses its private key to generate a public key and signs the login_code_to_sign with the private key. Signing the login_code_to_sign with the private key generates what is called the signature. Sending the public key along with the signature categorically guarantees to the recipient that the message was sent by the owner of the private key from which the public key was derived (and that the message wasn't modified in transit).
-
XYZ sends the triplet of login_code_to_sign, signature, and the public key to the auth server's
authorize/login
endpoint.-
Mobile client app case: XYZ first sends the triplet to the mobile client app, which then passes it to
authorize/login
. -
Client desktop site case: XYZ sends the triplet to
authorize/login
directly.
-
-
The auth server's
authorize/login
endpoint recognizes the original login_code_to_sign and can use the public key to decrypt the signature back into this exact login_code_to_sign. This guarantees to the auth server that the original sender of the triplet is the same entity as the holder of the private key used to generate this public key. As a result, the auth server can now advise the client that it is safe to display to the end user the logged-in part of their interface (desktop website or mobile). Additionally, the auth server sends to the client a code to be exchanged for an access token at the auth server'stoken
endpoint. -
The client sends the code (as well as the PKCE code_verifier) to the
token
endpoint. -
The
token
endpoint issues an access token to the client.