Silent Authentication - myMLA SSO

Silent Authentication allows authenticated users to move between sites that are protected by the myMLA SSO platform.

On this page

The OpenID Connect protocol supports a prompt=none parameter as part of the query string for the authentication request, allowing applications to indicate that the authorisation server request any user interaction (such as authentication, consent, or MFA). The authorisation server will either return the requested response back to the application, or return an error if the user is not already authenticated or if some type of consent or prompt is required before proceeding.

To use Implicit Flow in Single Page Applications, use the Authorization Code Flow with PKCE in conjunction with Silent Authentication to renew sessions.

Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies; therefore, browser-based flows must use Refresh Token Rotation, which provides a secure method for using refresh tokens in Single Page Applications, while providing end-users with seamless access to resources without the disruption in user experience caused by browser privacy technology like Intelligent Tracking Prevention.

Make The Request

To initiate a silent authentication request, add the prompt=none parameter to the url query string when you redirect a user to the /authorize endpoint of the authentication API. (Other individual parameters on the authentication request will vary depending on the specific needs of your app.)

Example Url

            
                GET https://YOUR_DOMAIN/authorize
                    ?response_type=id_token token&
                    client_id=...&
                    redirect_uri=...&
                    state=...&
                    scope=openid...&
                    nonce=...&
                    audience=...&
                    response_mode=...&
                    prompt=none

Success Response

If the user was already logged in and no other interactive prompts are required, the authorisation server will respond exactly as if the user had authenticated manually through the login page.

The response is exactly the same as a login performed without the prompt=none parameter.

For example, when using the Implicit Flow, (response_type=id_token token, used for single-page applications), the authorisation server will respond with the requested tokens:

            
                GET https://YOUR_APP/callback
                    #id_token=...&
                    access_token=...&
                    state=...&
                    expires_in=...

Error Response

If the user was not logged in or their session had expired, the authorisation server will redirect to the specified redirect_uri (callback URL) with an error:

            
                GET https://your_callback_url/
                    #error=ERROR_CODE&
                    error_description=ERROR_DESCRIPTION&
                    state=...

The possible values for ERROR_CODE are defined by the OpenID Connect specification:

Response	Description
`login_required`	The user was not logged in, so silent authentication is not possible. This error can occur based on the way the tenant-level Log In Session Management settings are configured; specifically, it can occur after the time period set in the Require log in after setting.
`consent_required`	The user was logged in, but needs to give consent to authorise the application.
`interaction_required`	The user was logged in and has authorized the application, but needs to be redirected elsewhere before authentication can be completed; for example, when using a redirect rule.

Poll With checkSession()

In some multi-application scenarios, where Single Logout is in use (a user logging out of one application needs to be logged out of all other applications), an application can be set up to periodically poll the authorisation server using checkSession() to see if a session exists. If the session does not exist, you can then log the user out of the application. The same polling method can be used to implement silent authentication for a Single Sign-on (SSO) scenario.

Note: The poll interval between checks to checkSession() should be at least 15 minutes between calls to avoid any issues in the future with rate limiting of this call.