CODEWITHSUNDEEP
reactjsactive-directorysingle-sign-onopenid-connectokta
StarLord
StarLord

Reputation: 1003

Is it possible to implement open id connect SSO in ReactJS with IDP independent code?

I have created an SSO in open id connect using Okta as a primary identity provider in a ReactJS and .NET 5 application. The problem is that, for using other Identity Providers like Azure Active Directory, it should be done through configuring in Okta portal. I want to implement it in such a way that the application can be connected to any Identity Provider without getting tied down to one particular Identity Provider. Is this possible? If it's possible please tell me how I should proceed? Any help help is much appreciated.

Please note that I am not looking to simultaneously connect to different identity provider.

Upvotes: 2

Views: 1857

Answers (3)

StarLord
StarLord

Reputation: 1003

I implemented this using oidc-client for the ReactJS application and IdentityServer4 for the .NET 5 api. If you want to know more about the implementation part, check this article here.

For connecting external identity provider to IdentityServer4, you can refer this documentation

Upvotes: 1

Chris Concannon
Chris Concannon

Reputation: 443

The correct way to do this is to federate the identity providers that you'd like to allow in order to manage your users, scopes, claims etc. from a single source of truth - I'll explain a lot below.

This means picking one identity provider as that source of truth (Okta in this example) and connecting auxiliary identity providers to your source-of-truth IdP (connecting Azure AD to Okta as a federated identity provider).

Getting into details, the reason that you want a single source of truth is because each token that is minted and sent to the ReactJS app will need to be validated by the app, in order to be sure that the token(s) came from an authorization server that the app trusts.

On a very granular level, each OIDC id_token and access_token that your ReactJS app receives has a iss (issuer) claim. The tokens are also signed using asymmetric encryption, which allows the token payload to be validated using a public key. This lets your ReactJS app OIDC library verify that the token information came from a trusted source - a source that you've explicitly configured.

Using multiple primary identity providers means the app would need to be configured to trust multiple iss values and fetch public keys from multiple jwks endpoints, and this is not a capability that is built into OIDC client library implementations.

OIDC libraries assume that your tokens come from a single source, and that the iss & aud claims, and the IdP's jwks endpoint (to fetch public keys to validate token signatures) will remain consistent for all user authentications.

Example id_token payload from auth0:

{
  "iss": "http://my-domain.auth0.com",
  "sub": "auth0|123456",
  "aud": "my_client_id",
  "exp": 1311281970,
  "iat": 1311280970,
  "name": "Jane Doe",
  "given_name": "Jane",
  "family_name": "Doe",
  "gender": "female",
  "birthdate": "0000-10-31",
  "email": "[email protected]",
  "picture": "http://example.com/janedoe/me.jpg"
}

and you can see the public keys that can be used to validate tokens issued by auth servers from my-domain.auth0.com at this endpoint: https://my-domain.auth0.com/.well-known/jwks.json

Upvotes: 1

Gary Archer
Gary Archer

Reputation: 29301

The standard pattern is to use an Authorization Server (Okta in your case), then to ensure your apps connect to it using standards based OpenID Connect messages. The AS then manages connections to other providers for you, eg:

  • Azure AD
  • Social logins
  • SAML systems

Your apps then only work with tokens from the AS, and you can fully control claims in APIs and session behaviour in UI clients.

Your apps remain simple and you can change how authentication works by just configuring the AS, with zero code changes.

You should also keep the code in your apps standards based, and you will then be able to switch AS in case ever needed. I tend to do this by using open source libraries instead of vendor specific libraries.

LIBRARIES

A couple of years ago oidc-client was the preferred open source library for SPAs:

More recently, browser restrictions have meant there is a trend to move in a Back end for front end direction. If you are building something new I would recommend use of this. Unfortunately SPA security is hard:

Upvotes: 2

Related Questions