If you read the previous article OAuth using AWS Cognito, then you should be also reading this. I’m writing this article after a month of this very story. But I believe I won’t miss much.

SAML, OIDC setup and overview

If we look into the out-of-the-box social identity providers , there are few. If we want to add Microsoft/Azure, that would be done via SAML or OpenID connect.

Due to our client requirement, we started working on integrating Azure (now Entra) into Cognito via SAML. In Azure, to setup SAML, we start by creating an Enterprise Application.

The integration was successful and we were able to login with our organization email. This itself was not straight, I was facing exactly this issue , mismatch in user attributes. Thanks to the Chrome Extension for recording SAML messages (as that answer says). That is the way to debug SAML setup. Its a neat tool. IMO, SAML was not the straight integration.

OpenID connect in Cognito with Azure Multi-tenancy

This moved on, we were only able to login with our organization’s email from which the SAML app was created. This means, if you have created the Azure Enterprise App with you@org,com, only users from org were able to login. This was surely not what we wanted. This encouraged us to look into the OpenIDC way.

Cognito Ms/Auth0

IMO, OpenIDC is comparatively straight to setup in Cognito and in Azure. Cognito has a general guide to setup any federated identity via OIDC . Set up an OpenID Connect provider with Microsoft Entra ID - here

As above setup guide says, you can provide an issuer URL and Cognito will populate values for the authentication endpoint, token endpoint, userInfo endpoint, and jwks_uri. The auto-filling never worked for me. If you go-to https://login.microsoftonline.com/{tenant}/v2.0 where the tenant is the Directory (tenant) ID in Azure, it will give you all the endpoints required by OpenID Connect. I suggest filling those endpoints manually. Again, auto-fill failed silently for me and I spent long time debugging without knowing what went wrong. So, Cognito is not so brave in auto-filling it. Technically it could be a bug? anything failing silently is inherently bad IMO. Anyways, here is my whole setup.

FYI Authorized scopes can be openid email profile.

cognito-azure-1

This time in Azure application, we chose the option “Accounts in any organizational directory and personal Microsoft accounts” In Supported Account types while setting up the app. This option will allow users who have personal Microsoft accounts and users from another tenant to access the application.

Read more: Validation differences by supported account types. 1- Accounts in this organizational directory only (Single tenant) - This is the default mode unless we choose not to. 2- Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant) - This is the Multi-tenant aspect Azure has.

Entra OIDC App settings

Not very late, we hit up on the same issue, users with their personal accounts or other 365 accounts (Multitenant) could not sign-in to our app.

Cognito failed me

I spent almost two days debugging this issue until I decided to search if this issue in depth which i did not do. I saw this question asked by someone telling the same issue 401 error getting token, bad id-token issue. Okay, this was it. We contacted AWS Support regarding this and they responded saying “Cognito doesn’t yet support multi-tenant authentication”.

[gasp]

I mean, why they never mentioned this was not supported in Cognito? I have looked into this even more and found more relevant threads.

You (AWS) guys should state flat out in your docs you don’t support MS Azure multi-tenancy. Would save people a lot of time over an otherwise essential feature

I could not agree with above comment anymore. In response, I’ve added my comment as well so that somebody else can some time in future.

Since Cognito does not support Multi-tenancy aspect - especially with Azure AD (as of wrting this post), you should move ahead and try other identity providers like Auth0, which is what i’m using right now. You see, its evolving. Everybody is learning from mistakes. But a clear documentation can save time of many. This knowledge would not have been possible without the stack-overflow answer which was my starting point. Thats it? When I looked back, we had many things to loose. Our whole system is around Cognito user management and Cognito multi-tenancy.

Auth0 as OIDC broker

Reset everything, whats the problem here? Cognito does not support multi-tenancy offered. Therefore, only users within your org can sign-in. At this point, I was lack of motivation and then I saw this question. As the answer says:

There are identity providers which support this dynamic iss claim behavior of Azure AD. (Auth0, Azure AD B2C, etc). So we can select one of them and configure that to communicate with Microsoft (Azure AD) via OIDC. Then add that IDP as an OIDC identity provider in Cognito. Basically we place that IDP in between Cognito and Microsoft (Azure AD).

So, the idea would be this; Cognito <-> Auth0 <-> AzureAD . Since Auth0 does support multi-tenancy of AzureAD, we use it and the final authorization will be handed over to Cognito. Yes, users will be created in both Auth0 and Cognito. Just setup Auth0 broker as how you would setup any OIDC provider in Cognito. My suggestion would be to fill in the OIDC endpoints manually.

userinfo endpoints

We made a complex auth system

Okay, tbh this is a fairly un-scalable system. But if you see, it still works. We have had this auth system running fine for almost a month in our development. And nobody asked “how it works” because all they see the Cognito login page and it gets redirected to Auth0. Since it got redirected to Auth0 for Microsoft logins, questions started coming as “why it is how it is”. This is the point of concern. I mean, we knew this would not be the right fit and is not a longer solution. I mean, we did not want to give up in the half way tho we knew the bitter truth. After all, its a journey, we learn from mistakes :)

I’m going to write how we can implement social login with multi-tenancy using Auth0 as Idp and much more in next article (possibly). If you have any questions/suggestions about this, let me know