Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Supporting Microsoft OIDC

See original GitHub issue

The issue

What version of UAA are you running?


How are you deploying the UAA?

I am deploying the UAA

  • using cf-deployment

What did you do?

We configured an OIDC identity provider for Microsoft using this discovery document, in order to allow logins from any Microsoft product (i.e. not just a specific Azure AD)

What did you expect to see? What goal are you trying to achieve with the UAA?

We’re in the process of enabling Microsoft single sign-on for tenants, whose accounts may be in any directory. We expected that, given the global discovery document, the login flow would just work.

What did you see instead?

We found that Microsoft issues tokens whose iss claim is different from the issuer given in the discovery document. This caused UAA to believe the token was invalid.

After some investigation, we found that the iss claim includes the GUID of the organisation to which the user belongs in Microsoft land (as is evident from the discovery doc:{tenantid}/v2.0). For some users (like Outlook or Hotmail users), the organisation GUID is well known. However, for corporate users, it will be their Azure/Office 365 tenant id.

For us, it is impossible to set an issuer URL that UAA would accept for all users.

The suggestion

@46bit and I have put together a small change in our paas-uaa fork which introduces a new configuration flag for OIDC providers: issuerValidationMode. The flag has three possible values: strict (the default), domain_only, and none.

The aim our of change is to provide a less strict form of issuer claim validation, in order to support scenarios like that posed by Microsoft SSO. In domain_only mode, the only the host portion of the token’s iss claim must match that of the configured URL. This is done as a string comparison, so subdomains are not considered to match a parent domain. E.g. is not a match for, or vice versa 
 We’ve deployed this change in to our CloudFoundry deployment, and verified that we can do a successful Microsoft SSO login.

Why an issue and not a PR

We’re raising this as an issue and not a PR because we’re not sure if this necessarily the right approach to take, and we’d like some feedback on the problem and our proposed solution.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:5
  • Comments:9 (4 by maintainers)

github_iconTop GitHub Comments

46bitcommented, Jul 31, 2019

@aeijdenberg While I appreciate your concern I wouldn’t underestimate how much investigation we did to get to this issue being filed and our modification running. We use Microsoft’s oid claim, described by as:

oid: The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they’re considered different accounts, even though the user logs into each account with the same credentials.

aeijdenbergcommented, Jul 30, 2019

Notwithstanding the above, I just realised precisely what you mean - it’s not just the docs that says {tenantid} in the URL, they actually bake that into the Issuer URL returned as:{tenantid}/v2.0.

Sigh - that makes things more difficult. I wonder if the reason for doing is that unlike Google’s Identity Platform, where all users (when identified by email) draw from a global namespace, whereas in Microsoft’s Identity Platform, can users with the same email address for example existing in multiple tenancies?

i.e. perhaps one needs the combination of tenancy and username/email in order to uniquely identify a user? Else I could spin up a new Azure AD tenancy, create a user with name “” and then use your sign-on (which ignores the tenancy) to impersonate you on your UAA?

Read more comments on GitHub >

github_iconTop Results From Across the Web

OpenID Connect (OIDC) on the Microsoft identity platform
Sign in Azure AD users by using the Microsoft identity platform's implementation of the OpenID Connect extension to OAuth 2.0.
Read more >
OpenID Connect authentication with Azure Active Directory
OIDC lets developers authenticate their users across websites and apps without having to own and manage password files. This provides the app ...
Read more >
OAuth 2.0 and OpenID Connect protocols on the Microsoft ...
A guide to OAuth 2.0 and OpenID Connect protocols as supported by the Microsoft identity platform.
Read more >
Add an OpenID Connect-based single sign-on application
Add an application that supports OpenID Connect (OIDC) based single sign-on (SSO) to your Azure Active Directory (Azure AD) tenant.
Read more >
Configure an OpenID Connect provider for portals with Azure AD
Learn how to configure the OpenID Connect provider for portals with Azure Active Directory using Implicit Grant flow.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found