Use openid connect as SSO for multiple applications

Question

I am trying to use openid connect to create a SSO for my application.

Basically we have one API layer and different Apps (clients) will consume the service of this layer.

To start with we added OAuth2.0 for authorization for each of the different apps; for authentication we are currently using our own database (IDP)

We want to the end users to have a single sign on experience for this flow. To have that we added openid on top of the OAuth flow we have built.

The web server has the standard oauth + openid implementation and has the following

• Explicit Flow
• Implicit Flow
• Password Grant

On adding the openid connect, the server now has the ability to send the id_token (jwt) as well, depending on the scope and request type

There are two clients registered (C1 & C2)

Step 1: C1 follows explicit flow and uses response type as code, so when a user (U1) access C1 it is redirected to the authentication server where U1 enters the credentials.

Step 2: The authorization server validates the credentials and prompts for the user consent, confirming which sends out the code to the redirect_uri of C1

Step 3: C1 then requests for a token and the server gives out an access_token and an id_token; the access token being persisted in the database

Step 4: U1 now needs to access C2

Questions:

• What would be the best way/practice for C2 to get the access token from the api sever without having the user to login again.
• If C1 passes the jwt id_token to C2 through local-storage or any other means, one possible way would be to exchange the id_token for an access_token following this.
• If we go with the above approach, would it be sufficient to just verify the id_token and issue the access_token or should we add any other check
• Any other approach.

Thanks

Answer 1

Choice of flow will depend on type of client. For example, client could be a native application, which can use Authorization code flow (I guess you refer Explicit Flow to this flow). Or JavaScript application which solely run on browser.

Solution - Session cookie based SSO

In OAuth 2.0 (including OpenID Connect), end user (ex:- U1 as in your example) authentication occur through browser interaction. In this process, usually authorization server establish establish a session. What this session does is keeping a reference to previously authenticated user. For example, this allows user to access IDP and update user contented there (if your identity provider support such).

Now, if both applications use the same browser (ex:- Microsoft Edge) to show the login screen in authorization request of OpenID Connect, your authorization server can check session cookie existing with the browser.If this is the case, authorization server can skip login screen and response with relevant content. Following is sample scenario with a fresh login

1. C1 stats and sends authorization request
2. Authorization server receives the request and check for a session cookie.
3. Since this is a fresh start, no cookie exist, so login is present
4. User U1 login
5. Authorization server send response and C1 complete token obtaining
6. C2 starts and sends authorization request
7. Authorization server receives the request and check for a session cookie.
8. Since we are using the same browser, session cookie exists and correlated user is identified as U1
9. Authorization server send response and C2 complete token obtaining

Now both C1 and C2 have U1 user logged in to them. This is browser based SSO.

Answer 2

if those clients are web applications the best and recommended flow to use is the Implicit flow for some reasons:

• it is secured in that case if you compare it with the hybrid flow, because the hybrid flow share a secret key with the clinet, and the client have to keep it, this key is used to generate acces_tokens, on the other side Implicit flow provide an access-token directly to the client with a short life time, so the best is to provide an access_token with short life time than an authorization key with long lifetime that can be used to generate tokens.

• SSO (single sign on) will work perfectly between client that share the same STS server, so C2 can have an access_token without authentication, here is the steps:

  1. C1 authenticate and get and id-token and an access_token

  2. a session cookie is created for this active session

  3. C2 click login and will get directly an access_token without authentication because the browser will send a valid cookie created from C1 authentication