Prompting for Login during SSO

Why Prompt for Login During SSO?

A login prompt during SSO (Single Sign-On) occurs when a user is required to enter their credentials, although they are already authenticated. In an ideal scenario, SSO enables smooth access to multiple applications without the need to log in repeatedly. However, in certain situations, you want to trigger a fresh login. Examples of these situations may include:

• The user switches between different apps
• Different authentication methods during a session
• Misconfigured SSO settings
• The user logging in from a different device or network
• Conditional access rules imposed by the organization using SSO

This article discusses how you can allow the client to manage SSO prompts based on the duration of sessions or OpenID Connect parameters.

Assume there are two websites, Site A and Site B, that use the same identity server. Assume also that Site B always needs to force a login, no matter what the current status of the SSO session is.

1. Site A runs the regular flow, an SSO session is established by the identity server, and Site A gets the ID token as usual. When Site B sends its authorization request, it includes the query parameter prompt=login.

2. The identity server shows the available authentication methods.

3. The user authenticates.

4. The identity server updates the SSO session.

5. The identity server returns an ID token to Site B.

6. Site B validates and uses the token to optionally create its own web session.

Parameters Controlling SSO

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

These parameters are optional in OpenID Connect. They allow the client to specify and modify the configured authentication behavior. You can think of them as instructions for the identity server.

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.

The client can make decisions about when to prompt based on any criteria you like.

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

• 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

The possibilities are endless. However, you should keep the user experience in mind.

Max Age

A more lenient way is to require a recent authentication. The client can control this by passing in the max_age query parameter in the request. The parameter value specifies the number of seconds since the last login. The identity server will enforce that all authenticators (in a multi-factor flow) have been 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 a new authentication 30 minutes after the last authentication, the client passes max_age=1800 to the server in the authorization request.

Verifying Freshness

To verify a login is new, the client only needs to check whether the auth_time parameter in the resulting ID token contains a recent enough timestamp.

Letting the Client Manage SSO

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.

More information

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

Last updated: 2025-02-05

Curity