javascriptreactjsamazon-web-servicessingle-sign-onamazon-cognito

SSO Integration between 2 webapps using Cognito


We have a requirement where we need an external partner's users to be able to access our web application.

External Partner set up : Web app with Cognito User pool on their own AWS account

Our set up : React App with Cognito user pool (username/password authentication) on our AWS account.

The requirement is : Our partner's users will login into the partner's website. Once authenticated, they will land on the home page and see a link to our website. Upon clicking the link, our webapp must be launched in a new tab, users must be verified(probably provisioned in our Cognito prior to that) and allowed access to our applications home page without the need to sign in again.

Our app is a React SPA hosted using S3/Cloudfront. We have a app client for the UI set up in Cognito. When a user attempts to access the app, they are presented with a custom login screen. Once credentials are verified(done using Amplify Auth in the React App) tokens are created in local storage and used thereon to invoke REST APIs etc.

Therefore we need to replicate similar behavior for users accessing our site from the partners website.

Have been reading articles related to SSO / OAuth 2.0 / OIDC looking for information on:

Found a article that talks about federating 2 Cognito's :

https://community.aws/content/2bUvwgyFoeJdjGYgpnRkejYAgYC/how-to-add-cognito-as-oidc-identity-provider-in-cognito?lang=en

But this set up means our partners users will have to sign in(using iDP federation) to access our app which is not the intended behavior(using SSO to be able to access both sites seamlessly).

If anyone has any solutions / pointers, kindly share, it will be much appreciated.


Solution

  • The link you posted shows the correct OIDC solution. What that link calls the "customer user pool" is really what you are calling your partner app. It is the OIDC identity provider. The login will not use your app, but will use the login page of the partner's website. The fact that the partner's website is implemented using Cognito is immaterial. The partner could be Facebook, Google, or some other OIDC provider. In any of these cases, your app initiates the login with the partner using OIDC, and once logged in the OIDC provider (partner) will send info back to you that you can use to establish the user, which is what is shown in step 12 of the diagram on the page you referenced--image copied here:

    Auth flow between 2 Cognito pools, as shown on https://community.aws/content/2bUvwgyFoeJdjGYgpnRkejYAgYC/how-to-add-cognito-as-oidc-identity-provider-in-cognito?lang=en

    If the users have already logged in on the partner's website, then when your app initiates the step #2 request in that diagram (that is, you redirect their browser to the "authorize" endpoint to kick off the authentication process with the OIDC provider), the partner website will recognize them and won't force them to type their credentials in again. It will use the credentials they already established and will issue tokens back to your Cognito which your Cognito can and will use to identify and establish the users. They will show up in your Cognito with a Confirmation Status of "External provider."

    The key point is that Cognito is an OIDC provider. So you can integrate it just like you can with any OIDC provider.

    1. The partner will need to give you a client ID/secret to use when you set up your federated identity provider in Cognito. So yes, they will need to set up a client for your app.
    2. You will need to set up a federated identity provider in your pool. You will use the info provided above along with other details like the issuer URL and potentially other endpoints to do this.
    3. You can give the partner website a URL to your web app that will initiate the "authorize" flow (i.e. will redirect the browser to the authorize endpoint).
    4. Your app code may need to be updated with a page that the partner web app can target which will initiate the login process (i.e. redirect to the "authorize" endpoint).