This article shows you some cases of how you can adjust the SSO behavior depending on the authentication methods used by the user.
Curity Identity Server supports many different authentication methods which can be available to your users. The difference between them is not only in the very action the user undertakes, but also in the level of security a given method provides. Some methods may have increased security but at the same time be quite cumbersome, which may impact the user experience. This means that very often it will valuable to define different behaviors for SSO depending on which authentication methods were used to authenticate the user in the first place.
An important part of SSO is to provide a smooth user experience. But it can conflict with high security requirements. It is important to find a good balance between those two - where you want to maintain an acceptable level of security, without impeding the UX. The Curity Identity Server gives you tools to cover some of the most popular scenarios.
One solution is to require different authentication methods at different time intervals. Methods which are more secure, but at the same time, more cumbersome for the user, can be required less frequently. Less involving methods, on the other hand, can be safely required more often, without boring the user too much.
This behavior can be achieved by changing the expiration time for the SSO session, individually for each authenticator. The SSO session in the Curity Identity Server will effectively be kept separately for different authentication methods, and will require re-authentication with a given authenticator only if the expiration time for the given authenticator has passed.
|Profile||3600 seconds||If not configured on an authenticator this applies|
|Username/Password Authenticator||1 day||Require password every day|
|SMS Second factor||30 days||Require second factor every month|
With the above configuration for SSO expiration we can achieve a more user friendly login flow.
- Day 1: The user accesses the site for the first time and is prompted with both Username/Password and SMS.
- Day 2: The user accesses the site using the same browser. Curity already knows this browser and will request only the Username/Password.
- Day 31: Even though the user still uses the same browser, they will need to re-authenticate using both factors.
This is a common setup for sites that the user accesses frequently.
A different approach can be used if your application / website is clearly divided into different parts or sections with different security requirements. For example, on an e-commerce website you could allow your users to log in only with their username and password when they just want to browse items and put them in the cart. But when the user wants to place an order, or access their profile data or saved credit card numbers you ask them to re-authenticate with a stronger authenticator - like an SMS factor.
In the Curity Identity Server this can be configured so that the SMS authenticator will depend on a successful login with the username/password authenticator in the SSO flow. Then you can have these different scenarios:
- A user comes to the website, directly to their profile page. Since they are not logged in and this is the profile page they will have to authenticate with both factors - username/password and SMS. Then the user can freely browse the inventory and place orders.
- Another user comes to the inventory page. They log in with just the username/password authenticator and start adding items to the cart. Finally they want to place the order. Placing the order requires a token issued with a stronger authenticator, so the user will be asked to re-authenticate. Since they have an active SSO session created with the username/password authenticator they will only have to authenticate using the SMS factor.
SSO can give your users a lot of positive experience. At the same time you can maintain high levels of security through adjusting the expiration settings of SSO sessions appropriately. You can also improve user experience by cleverly requiring authentication methods in the access tokens issued by the Curity Identity Server.
For more information, see the authentication service product documentation for more info.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.