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.

Technical Flow

@startuml

skinparam shadowing false

skinparam BoxPadding 10

skinparam sequence {
    ArrowColor #168CA9
    LifeLineBorderColor #047D82

    ParticipantBorderColor #168CA9
    ParticipantBackgroundColor #168CA9

    ParticipantFontName Frutiger
    ParticipantFontColor white

    ActorBackgroundColor #168CA9
    ActorBorderColor #168CA9
    ActorFontName Frutiger

    GroupBorderColor #168CA9
    GroupBorderThickness 1

    DividerBackgroundColor #168CA9
    DividerBorderColor #168CA9
    DividerBorderThickness 1
    DividerFontColor white
    DividerFontName Frutiger

    BoxBorderColor #168CA9
    BoxBackgroundColor #ECECEC
}

skinparam note {
    FontName Frutiger
    BorderColor #168CA9
    BackgroundColor #F5F5F5
}

title Out-of-Band Usernameless Authentication

actor User as user

box "Desktop Client Device" #F5F5F5
    participant "Browser" as browser #75C3D7
end box

box "Mobile Device" #F5F5F5 
 participant "Nevis Access App" as app #75C3D7
end box

box "Nevis Backend" #CDD2D4
    participant nevisProxy as proxy
    participant nevisAuth as auth
    participant nevisFIDO as fido
    participant nevisIDM as idm
end box

participant "Customer Application" as backend #75C3D7

user -> browser: Login
browser -> proxy++: access customer application

proxy -> browser--: Login required (""HTTP 302 /?login"")
browser -> proxy++: Initiate login (""HTTP GET /?login"")
proxy -> browser--: render login page

autonumber

browser -> proxy++: HTTP POST ""{"dispatcher":"png-qr-code"}""
rnote over proxy #F5F5F5
    IdentityCreationFilter
end note
proxy -> auth++: authenticate

rnote over auth #F5F5F5
    OutOfBandFidoUafAuthState
end note

group HTTP API: Dispatch Token Service
  auth -> fido++: POST ""token/dispatch/authentication"" \n ""dispatcher" : "png-qr-code"""
  fido -> fido: Generate ""token"" and\nstore ""GetUafRequest""
  fido -> auth--: Dispatch token response\n(sessionId)
end group

auth -> auth: Cache ""sessionId""

auth -> proxy--: Token dispatched (""DispatchTokenResponse"") \n QR Code information
proxy -> browser--:\n Render QR Code

loop
    browser -> auth++ : query status with ""sessionId""
        
    rnote over auth #ECECEC
        OutOfBandFidoUafAuthState
    end note

    group HTTP API: Status Service
      auth -> fido++: StatusRequest
      auth <- fido--: ""tokenCreated""
    end group
   
    browser <- auth-- : Authentication status: ""tokenCreated""
    
    note right
    The value returned can be one of the following
    according to the current authentication status: 
    ""tokenCreated"", ""clientAuthenticating"", ""succeeded""
    end note
end

user -> app++: open Access App
user -> app: scan QR code

group HTTP API: Redeem Token Service
  app -> fido++: POST ""/token/redeem/authentication"" (""token"")
  fido -> app--: ""uafRequest"" 
end group

app -> user: Query credentials
user -> app: Supply credentials

group HTTP API: Authentication Response Service
  app -> fido++: POST ""uaf/1.1/authentication"" (""uafResponse"")
  fido -> app--: Server response    
end group

app -> user--: Authentication successful

browser -> auth++ : query status with ""sessionId""
    
rnote over auth #ECECEC
    OutOfBandFidoUafAuthState
end note

group HTTP API: Status Service
  auth -> fido++: StatusRequest
  auth <- fido--: ""succeeded""
end group


auth -> auth: Auth state transition

rnote over auth #ECECEC
    IdmUserVerifyState
end note


auth -> idm++: load user information
idm -> auth--: user information

auth -> auth: AUTH_DONE
rnote over proxy #F5F5F5
    IdentityCreationFilter
end note
auth -> proxy--++: Create authenticated session
proxy -> browser--: HTTP Redirect
browser -> proxy: HTTP GET initial request

proxy -> backend: Forward to relying party application

|||
@enduml

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

• OutOfBandFidoUafAuthState
• IdmUserVerifyState

nevisFIDO

• nevisFIDO Link Dispatcher
• nevisFIDO QR Code Dispatcher

HTTP APIs

• Dispatch Token Service
• Redeem Token Service
• Authentication Response Service
• Status Service
• Facets Service