Is there a standard pattern for OIDC based Social Login with IDaaS?

2
votes

Scenario: openid-connect based social login for SPA.

Case 1: In case of an SPA which has registered as an OAuth 2.0 client with Social Authentication Provider (ex. Google) the OAuth/OIDC roles map like this:

  • Resource Owner = Authenticating User
  • Client = SPA
  • Authorization Server = Social Authentication Provider (ex. Google)
  • Resource Server = Social Authentication Provider (ex. Google)

Case 2: Now, let's consider the case of Social Authentication for an SPA using an IDaaS (ex. Okta/Auth0). IDaaS has registered an OAuth 2.0 client with Social Authentication Provider (ex. Google) and SPA has registered an OAuth 2.0 client with IDaaS.

Question: Is this use case a combination of two OIDC flows (nested?)

Flow 1:

  • Resource Owner = Authenticating User
  • Client = IDaaS (ex. Okta)
  • Authorization Server = Social Authentication Provider (ex. Google)
  • Resource Server = Social Authentication Provider (ex. Google)

(at this point Social Provider has asserted id_token (iss=Google, aud=IDaaS) to IDaaS redirect_uri)

Flow 2:

  • Resource Owner = Authenticating User
  • Client = SPA
  • Authorization Server IDaaS (ex. Okta)
  • Resource Server: IDaaS (ex. Okta)

(finally, IDaaS has asserted id_token (iss=IDaaS, aud=SPA) to SPA redirect_uri, and at this point authentication to SPA is complete).

Is the above understanding correct?

Also, is there a standard OIDC/OAuth pattern for this kind of an architecture which involves use of an IDaaS as an identity broker?

1
oauth-2.0single-page-applicationopenid-connectauth0okta

1 Answers

2
votes

You are using a concept called OAuth 2.0/OpenID Connect federation. Rather than being a standard, identity provider vendors use this integrate external identity providers.

Case 1 purely use OAuth 2.0 and OpenID connect. SPA simply rely on Authorization server to issue tokens.

In Case 2, you rely on an external identity provider (ex:- Google as in your explanation) for user authentication. And if you compare your configurations, you are configuring IDaaS to be a client to Google. And then your SPA to be a client to IDaaS.

Is this use case a combination of two OIDC flows ?

No, it use the same OIDC flow. But instead of SPA directly contacting Google, IDaaS make the request (rather forward the request). IDaaS will create the authorization request and direct SPA to Google's login page.This is done by IDaaS obtaining registered details such as redirect URL, client id and client secret.

As the client, you get the login page and provide credentials. Once that's done, OAuth 2.0/OpenID Connect redirect occurs to IDaaS (Note - At Google we configured redirect URL to IDaaS). IDaaS will receive the redirect and process it. Depending on the flow used, there will be a token request involved in the step. Then it proceed to token processing.

In this step, internally, IDaaS will replace the token. It will first validate Google issued token. If token is valid, IDaaS will create a new token with claims required from Google as well as audience and issuer values set to SPA known values.

Basically IDaaS receives the original Google token. SPA receives the IDaaS created token. It is the same flow, but with a middle IDaaS working with an external identity provider.