- Newest
- Most votes
- Most comments
Hi,
As of now, Cognito does not support Multi-tenancy for integrating Microsoft accounts using Microsoft common endpoint "https://login.microsoftonline.com/common/v2.0".
We already have an Internal feature request with the Cognito team to support a Multi-tenancy environment when integrating Microsoft with Cognito.
We are unable to provide an ETA as to when this feature will become available as we are not made privy of development roadmap of future releases. But I'd advise keeping an eye on our "What's New" page and our Official Blog to stay up to date on feature releases.
[+] What's New: https://aws.amazon.com/new/
[+] Official Blog: https://aws.amazon.com/blogs/aws/
Thanks! We will stay tuned, I appreciate the response!
Hi AWS team, we run into the same problem,
the last post was 9Month ago with:
We are unable to provide an ETA as to when this feature will become available as we are not made privy of development roadmap of future releases. But I'd advise keeping an eye on our "What's New" page and our Official Blog to stay up to date on feature releases.
Is this finally implemented? Will it be ever implemented. Please provide an ETA, or just admit, that it will never be implemented, or is not a priority. This communication leaves us totally in the dark.
thank you
Hello Devon,
I understand that you want to use multi-tenant configuration for Cognito with Microsoft using OIDC.
I can confirm that your understanding of Cognito's current limitations is correct. Cognito currently does not support the issuer when set to "common" or "organization". The reason for this behaviour is with the current implementation of Cognito, the issuer registered in Cognito for the OIDC provider must correspond to "iss" attribute in ID token sent by your IdP for successful authentication into Cognito. In your configuration, the Issuer URL is registered in Cognito as "https://login.microsoftonline.com/common/v2.0", however the issuer URL sent for any tenant is in the format "https://login.microsoftonline.com/{tenant_id}/v2.0" which results in an issuer URL mismatch.
I understand this service limitation may be frustrating, and I've taken the initiative to add your voice to our existing feature request for multi-tenant Azure support. This will help increase the priority of its implementation. While I can't provide a specific timeline for this feature as we have limited visibility into service roadmap,, please know that AWS values customer feedback highly in prioritizing new features and improvements. You can stay updated on new feature announcements through our AWS Official Blog (https://aws.amazon.com/blogs/aws/) and What's New page (https://aws.amazon.com/new/).
In the meantime, here are some potential workarounds you might consider:
- Create separate Identity providers for each multi-tenant environment.
- Develop a Custom Identity Provider to act as a proxy between your application and Azure AD, handling the dynamic issuer claims.
- During my research, I came across a community discussion that addresses this issue. On a best-effort basis, I'm sharing this third-party resource (https://stackoverflow.com/questions/64331213/microsoft-oidc-in-aws-cognito-allowing-multiple-tenants) as a reference. Please note that AWS has not validated the accuracy of this solution, so proceed with caution if you decide to explore it.
Thanks, I appreciate the response! (I can only pick one selected answer :P) I think building a customer identity provider is unfortunately a bit too scrappy for our current desire to be in a more-managed solution. And unfortunately we cannot add identity providers for every possible business and school district, even with the very generous 1000 identity providers per pool, just not really practical I am sorry to say!
Thanks!
Amazon Cognito currently supports social sign-in with Facebook, Google, Amazon, and Apple as built-in social identity providers. While Microsoft is not explicitly listed among the supported social identity providers in the documentation, you can integrate with Microsoft using the OpenID Connect (OIDC) protocol since Amazon Cognito supports OIDC identity providers.
The challenge you're describing with Microsoft accounts relates to how the issuer URL works with multi-tenant scenarios and personal Microsoft accounts. When using the common endpoint (https://login.microsoftonline.com/common/v2.0), Microsoft returns tokens with tenant-specific issuer URLs, which causes validation issues in Cognito since it expects the issuer in the token to match exactly what was configured.
There is no explicit mention in the documentation about "Dynamic Issuer Resolution" or "Multi-Tenant Issuer Validation" as a current feature of Amazon Cognito. The documentation doesn't indicate any ongoing work to support this specific feature either.
As a potential workaround, you might consider:
- Using a custom authentication flow with Lambda triggers to handle the Microsoft authentication separately
- Implementing a token exchange service that sits between Microsoft and Cognito
- Using Amazon Cognito Identity Pools (Federated Identities) with your own authentication system for Microsoft accounts
For the most accurate and up-to-date information on this specific scenario, I would recommend reaching out to AWS Support directly as they would have visibility into any planned features or specific workarounds for Microsoft multi-tenant authentication with Cognito.
Sources
Using social identity providers with a user pool - Amazon Cognito
Add social sign-in to your user pool - Amazon Cognito
Features | Amazon Cognito | Amazon Web Services (AWS)
The redirect and authorization endpoint - Amazon Cognito
User pool sign-in with third party identity providers - Amazon Cognito
Relevant content
- asked 3 years ago
- asked 2 years ago

We are trying to implement Sign in with Microsoft as well -- this seems to be a major blocker. Unless we dedicate a ton of dev time to building some sort of proxy solution.