Skip to main content

Out-of-Band Usernameless Authentication

The usernameless authentication scenario follows the same principle as the normal out-of-band authentication use case.

The distinct differences of the usernamelss authentication scenario are:

  1. The end-user is not required to provide a username during the authentication scenario, as the name suggests.
  2. The scenario can only be used with either QR codes or links. Push notifications will not work as the backend is lacking the information where to send the push message to.
  3. The backend is only aware of the user attempting to authenticate after the authentication has been successful.

The usernameless authentication scenario is best used as a non-multistep login flow to provide the end-user the best possible convenience and user experience.

Prerequisites​

  • The user needs two devices at hand. One device is a laptop, where the user performs a legacy login. The other is a mobile device, where the user authenticates.
  • A mobile application is installed on the mobile device. This mobile application handles the FIDO UAF protocol as well QR code scanning.
    • The mobile application has to register itself against the backend as the receiver of out-of-band messages. Dispatch Target Management describes this procedure.
  • The user has previously registered FIDO Authenticator credentials on his mobile device.

Example with QR Code​

The numbers in the description below correspond with the numbers in the next figure.

  1. The user opens the e-banking application in the browser on the laptop.
  2. The e-banking application is protected by Nevis, which renders a login page with a QR code.
  3. The user scans the QR code using the mobile device.
  4. The mobile application contacts Nevis to proceed with the FIDO authentication.
  5. Nevis allows the laptop client to access the e-banking application.
Out-of-Band Usernameless Authentication Example

Technical Flow​

The numbers in the list correlate with the step numbers in the previous figure.

  1. The client javascript in the browser starts the authentication operation by sending a dispatch token request to the backend.

    The supported dispatchers for usernameless authentication are Link or QR-Code.

  2. The nevisProxy IdentityCreationFilter forwards the request to the nevisAuth OutOfBandFidoUafAuthState.

  3. The auth state starts the authentication by requesting a dispatch token from nevisFIDO using the Dispatch Token Service.

  4. nevisFIDO creates the token and stores the GetUafRequest obtained by nevisAuth for later redemption by the Access App.

  5. nevisFIDO returns the Dispatch Token Response to nevisAuth.

  6. nevisAuth caches the operations sessionId to track the authentication status through the operation.

  7. nevisAuth forwards the response to nevisProxy. The response contains the information to render the QR code or display a link.

  8. nevisProxy renders the QR code information or displays a link in the Browser and displays it to the user.

  9. The client JavaScript starts querying the progress of the authentication repeatedly.

  10. The OutOfBandFidoUafAuthState uses the supplied sessionId to query the nevisFIDO Status Service.

  11. The Status Service returns the current status of the authentication operation.

  12. nevisAuth reports the status back to the browser to inform the user.

  13. The user opens the Nevis Access App.

  14. The user scans the QR code displayed or clicks the link rendered in the browser.

  15. The Nevis Access App uses the Redeem Token Endpoint in nevisFIDO to obtain the UAF Request to process the authentication operation.

  16. nevisFIDO returns the UAF Request to the Nevis Access App.

  17. As part of the authentication, the Nevis Access App queries the user for previously enrolled credentials.

  18. The user supplies an enrolled credential.

  19. The Nevis Access App signs the authentication challenge and posts the UAF Response to the nevisFIDO Authentication Response Service.

  20. nevisFIDO reports the operation result back to the Nevis Access App. In this scenario, valid credentials are provided and the authentication operation succeeds.

  21. The Nevis Access App informs the user about the successful authentication operation.

  22. After this step, the status check loop executed in the browser by the JavaScript will receive a different status response. This call will lead the authentication flow to continue in nevisAuth.

  23. The OutOfBandFidoUafAuthState queries the nevisFIDO Status Service again.

  24. The result received from the Status Service indicates the authentication operation was successful by responding with succeeded.

  25. The OutOfBandFidoUafAuthState starts the ok transition, in this example leading the auth engine to transition to the IdmUserVerifyState.

  26. The IdmUserVerifyState uses the userId provided in the request object: ${request:userId}.

  27. The auth states load additional user information from nevisIDM.

  28. The auth engine reaches AUTH_DONE.

  29. nevisProxy is informed to create an authenticated session.

  30. nevisProxy issues a redirect towards the Browser.

  31. The browser accesses the original relying party URL.

  32. nevisProxy forwards the authenticated request to the customer application.

How does it work?​

Usernameless authentication may sound strange as the user is never asked to provide a login identifier and is able to authenticate by simply providing his or her authentication credentials. This chapter provides a simplified explanation of how the scenario works.

  1. When providing a QR code, the backend does not need to be aware of the user wanting to authenticate. Essentially, the backend poses a challenge which must be successfully signed, only specifying what is accepted to sign the challenge. In the FIDO UAF context, this is a list of allowed authenticators identified by the FIDO UAF Policy.
  2. By signing the challenge with a known and enrolled authenticator, the backend is able to identify the user who signed the challenge based on the unique authenticator credential ID contained in the UAF Response sent back to the server.
  3. The server looks up the credential used to sign the challenge and based on this is able to locate the user possessing the signing credential.

References​

nevisAuth​

nevisFIDO​

HTTP APIs​