SSO flow with IS4

1
votes

We have several web applications, all of which will be adapted to use a single authentication endpoint based on IdentityServer4 and OpenId Connect.

I would like some argumented advice regarding the following (simplified) flows that I'm considering.

  1. Cookies:

    1. User accesses app1 and hits Login
    2. User is taken to the IdP login page
    3. User logs-in and is taken back to app1
    4. app1 provides a link to app2, which is clicked by the user
    5. app2 takes her to the IdP login page
    6. IdP cookies haven't expired, and therefore, no user credentials are requested. Consequently, the user is auto-logged-in and taken back to the app2.

  2. Token-based authentication:

    1. User accesses app1 and hits Login
    2. User is taken to the IdP login page
    3. User logs-in and is taken back to app1
    4. app1 provides a link to app2, which is clicked by the user
    5. app1 redirects the user to app2 but also provides the id_token obtained previously from the IdP (item 2.3 above)
    6. app2 verifies that the id_token is valid and automatically logs the user in.

Questions:

  1. Which one is better? (Cookies vs. Token "sharing")
  2. Is there a different (i.e. better) flow I should implement?
1
single-sign-onidentityserver4openid-connectidp
Do you have sample for implementing Token-base Authentication as you have mentioned above. I want to learn it. – sameer
I don't, unfortunately. We ended up going with option 1, which comes out of the box with IS4. – joaco

1 Answers

1
votes

Flow #2 is preferred, and here's why I believe so:

The critical item in flow #1 is step 1.6 where app1's cookies are evaluated for expiration. the key here (in my opinion) is that cookies should be app-specific and app1's cookies should not be tested when app2's user is authenticated.

Conversely in flow #2, step 2.6 should be performed by app1 (as the referrer) so app1 and the identity provider agree that the authentication token is still valid and app2 can proceed using app1 as a deferred authenticating application.

IdP can legitimately validate (or refresh for that matter) a token from any application, whereas a cookie should be managed as application- (or session-) specific.

A 3rd more ideal method: Each app should have its own authentication context from IdP and when app1 authenticates, each of the linked applications can authenticate as well with the same user credentials. In this pattern, applications can expire tokens at different times (for example: viewing 2 hours, but editing only 30 minutes.) The key to this approach is that SSO credentials are accessed once, authenticated for all the application contexts, and token lifetimes are managed on a per-app basis from then on.