Improving Single Sign On with Back Channel Authentication

Single sign-on (SSO) is widely used in many enterprise systems to enrich customer identity and access management (CIAM) capabilities. SSO enables users to provide their credentials once and obtain access to multiple applications without being prompted for credentials every time. This article discusses an improvement that can be done to the front channel (browser-facing) SSO flow in order to improve user experience and reduce latency. After an SSO login to a service provider (a web application), the browser redirection to the identity provider can be avoided for subsequent logins with back channel authentication. This article discusses the applicability of back channel authentication using WSO2 Identity Server.

Why Do You Need Back Channel Authentication?

The main motivation behind replacing front channel authentication with back channel authentication is to improve the user experience provided by the CIAM solution. When front channel authentication is used, there will be browser redirections to the identity provider (IdP) to complete the authentication flow. These browser redirections are meaningless for the end users and make the process slower.

Back channel authentication allows server-to-server communication and thus removes the need for browser redirections. Many popular and widely used service providers, use back channel authentication when accessing their services. A well-known example is Google. When you log into your Gmail account and then access YouTube, you’ll notice that the authentication to YouTube happens via a back channel. You will directly be in the logged in YouTube page without any other redirections. In that way, back channel authentication is widely used to provide a seamless user experience when accessing multiple services.

When there are browser redirects among your applications, you need to have a security model that ensures safe redirections. Moreover, redirects affect mobile users more significantly because they are using less reliable mobile networks. Messages that are transmitted via a front channel are usually signed and often encrypted. These precautions are needed because the messages transit in a potentially hostile browser environment. When you move to the back channel protocol, you can rely on mutually authenticated TLS (Transport Layer Security) for end-to-end security as the communication is point-to-point. So, if you have a set of SSO enabled services, you can consider back channel authentication as an option to improve performance and user experience.

Prerequisites for Enabling Back Channel Authentication

In order to enable back channel authentication your service provider applications and the identity provider need to fulfill the following conditions:

• SSO is enabled among the service provider applications
• All service provider applications use federated login with the identity provider
• Redirection to the identity provider from any of the web applications is only needed when the user is not authenticated
• Each web application does back channel authentication to check whether the user has a valid session before redirecting the user to the identity provider

If you are planning to enable back channel authentication with WSO2 Identity Server, then your applications need to satisfy the below condition as well:

• Service provider applications and the identity provider are hosted on different subdomains under the same domain. E.g. sp1.test.com, sp2.test.com, idp.test.com

Overview of the Back Channel Authentication Flow

Login flow

Figure 1 below demonstrates the back channel authentication login flow when there are two service providers hosted in the same subdomain (e.g. *.test.com). There are two newly introduced extensions, a custom grant handler and a JSON Web Token (JWT) authenticator which are used to perform back channel authentication.

Figure 1: Back channel login flow

From step 1 to 8

When an unauthenticated user tries to log into one of the service provider applications, the user will be redirected to the identity provider for SAML SSO. Once logged in, the identity provider will create and issue a common authentication ID cookie (keeps track of a particular user’s session) and a SAML SSO token ID cookie (keeps track of the session index in the SAML session participant cache) for the subdomains under the same domain test.com.

From step 9 to 10

Now all the applications have access to these cookies since they are set for the subdomains in the user’s browser. So when the user tries to log into another service provider application, the back channel authentication component checks whether these cookies exist. If cookies are available then it proceeds to the back channel login by calling the custom grant type handler in the identity provider.

Step 11

Custom grant handler will do the following steps before returning a token:

1. Check whether the user session exists for a given common authentication ID cookie.
2. If yes, check whether the issuer is registered in the identity provider as a valid service provider.
3. If yes, add the issuer as a SAML session participant using the SAML SSO token ID cookie.
4. Issue the token.

Step 12

Issue signed JWT token in the token response along with the session index ID of SAML SSO session.

Step 13

Validate and authenticate the user using the JWT token received and create an application level session for the user. Then map the application level session with the session index ID.

Logout flow

Figure 2 below demonstrates the logout flow, which shows how logging out from a SAML SSO session invalidates back channel authenticated sessions and vice versa.

Figure 2: Back channel logout flow

Case 1: User logs out from Service Provider 1 (SAML SSO logged session)

• Since the user is logged into Service Provider 1 (SP1) by default in the SAML flow, SP1 sends a service provider initiated logout request.
• Once the logout request is received, the identity provider will send the back channel logout requests to all the service providers which have Single Logout (SLO) enabled.
• Since Service Provider 2 (SP2) is logged in by back channel, it will invalidate the local session mapped to the session index ID.
• Finally, the identity provider sends a SAML logout response to SP1 and SP1 will invalidate the local session mapped to the session index ID.

Case 2: User tries to log out from SP2 (Back channel logged session)

• Since the user is logged into SP2 by back channel, SP2 will trigger an identity provider initiated SAML logout request.
• The identity provider will send a logout request to all the service providers in the same SAML SSO session (SP1 and SP2).
• All service providers will invalidate their local session and SP2 will be redirected to the return URL specified in the logout request.

Guidelines for Implementing Back Channel Authentication

Changes to the SAML SSO flow

Figure 3 below represents the changes that need to be introduced to the SAML SSO login flow of service providers in order to enable back channel authentication. The implementation will be discussed in the context of WSO2 Identity Server.

Figure 3: Changes to be introduced to login flow

Components and their role

Apart from the changes to the SSO flow in service providers, you need to have the following components to enable back channel authentication:

1. Custom grant handler for WSO2 Identity Server:
   • This component will authenticate users based on the common Auth ID and SAML SSO token ID. You can refer to this documentation to write a custom grant type handler for WSO2 Identity Server.
2. Backchannel authentication component for service providers:
   • This component will recognize whether a session already exists for a service provider using common Auth ID and SAML SSO token ID.
   • If these cookies are available, then do back channel authentication by calling the custom grant type handler in WSO2 Identity Server.
   • Use a JWT authenticator to authenticate users and create application level sessions for users.
   • To manage back channel authenticated sessions: maintain authenticated sessions, and handle session invalidation and expiry.
3. JWT authenticator
   • To validate JWT tokens issued by the custom grant handler and get authenticated user information.

Summary

Back channel authentication can be done to an SSO flow to achieve many advantages such as improved user experience, reduced redirection delay, and the flexibility to reduce restrictions on the security model. Back channel authentication can improve both SSO login and logout flows to avoid browser redirections. These improvements lead to a better CIAM solution.

WSO2 Identity Server provides extension points to enable back channel authentication. You need a custom grant handler, a back channel authentication component and a JWT authenticator to enable back channel authentication with WSO2 Identity Server. WSO2 Public Cloud uses back channel authentication implemented using WSO2 Identity Server to provide a seamless experience to its users.