Prompting for Login during SSO

Managing authentication prompts by age or parameter.

Overview

What follows is a look at how you can allow the client to manage Single Sign-On (SSO) prompts based on duration of sessions or OpenID connect parameters.

Clients as part of the architecture

With a strong and flexible architecture, clients can be empowered to make decisions about how SSO should be managed, and when, if and how a authentication method should be prompted.

Letting the client manage

Giving the client options to handle SSO more actively based on session lengths or internal statuses provides deeper flexibility for the client and a better user experience in the entire service.

Curity Solution

We have Site A and Site B, an we want Site B to always force a login, no matter what the current status of the SSO session is. The solution is very straightforward:

1. Site A runs the regular flow, an SSO session is established by Curity, and Site A gets the ID Token in the normal manner.

2. When Site B sends its authorization request it includes the query parameter prompt=login.

3. Curity offers up the available authentication methods

4. The user authenticates

5. Curity updates the SSO session

6. Curity sends an ID token

7. Site B validates and uses the token to access resources

Prompt

The most powerful way to disable SSO from a client perspective is to send prompt=login on the request query string. This disables all usage of SSO cookies and forces a new authentication for all factors required.

The server will enforce the request, but the client is obligated to verify that the login is recent. This is to mitigate attacks where an attacker modifies the request query or starts another login tricking the client to accept the result.

Decisions about when to prompt can be made in the client, and can be based on any criteria you like.

Some examples when you could have the client require a new login:

• The user switches device
• The device moves between networks
• The device geo-location changes

You could also have the client act based on authentication parameters:

• Age of ID Token

Obviously the only limitation here is your imagination, and perhaps considerations about user experience impact.

Max Age

A more lenient way is to require a recent authentication. This can be controlled by passing in the max_age=300 query parameter in the request. It takes a value of number of seconds since last login. The Curity Identity Server will enforce that all authenticators (in a multi-factor flow) are used recently enough to match the max_age requirement. Any SSO session deemed too old will trigger a re-authentication for that factor.

Example

To force an authentication to have occurred the last 30 minutes the client passes max_age=1800 to the server in the authorization request.

Parameters Controlling SSO

A few of the request parameters specifically affect SSO; acr_values, max_age and prompt.

They are optional, but by passing these parameters, the client can specify authentication and modify the configured authentication behavior. You can think of them as instructions for the authentication service.

Verifying Freshness

To verify that a login is new all the client needs to to is verify that the auth_time parameter in the resulting ID Token contains a recent enough timestamp.

More information

For more information, see the Curity Product Documentation on SSO.