Prompting for login during SSO
Managing authentication prompts by age or parameter
What follows is a look at how you can allow the client to manage 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.
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:
Site A runs the regular flow, an SSO session is established by Curity, and Site A gets the ID Token in the normal manner.
When Site B sends its authorization request it includes the query parameter
Curity offers up the available authentication methods
The user authenticates
Curity updates the SSO session
Curity sends an ID token
Site B validates and uses the token to access resources
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.
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. Curity 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.
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;
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.
|Governs the allowed authentication method for SSO.||Requests that Curity uses a certain authenticator (or group of authenticators). Multiple strings are separated with space.|
|Specifies a maximum allowed age for the SSO session (in seconds)||If the session is older, the user is prompted to login again.|
|Lets the authentication server know that login should be required.||Allows for the client to force new authentication.|
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.
Always verify freshness
If the client depends on a login being recent or new it is obligated to verify the
auth_time parameter in the ID Token.
For more information, see the Curity Developer Portal on SSO.