Azure Active Directory 令牌验证

Question

I'm integrating Azure Active Directory into a cloud platform. As our application is multi-tenant and relies on platform-specific claims, we've identified the simplest way to go about this is get an Azure AD token via our SPA, pass it back to our WebApi, validate it and return to the SPA a platform token with all the claims we need to go about our normal business (as if it was a simple username/password athentication request).

I'm concerned at the level of security for this though.

Some Context
As our platform is multi-tenant, we request that clients each register the application on their Azure AD portal, then supply us with the generated Application (client ID) and Directory (tenant) ID . We use these two pieces of information to make the initial request to Azure via our front-end SPA (following the node.js example provided by Microsoft's Quickstart guide when registering an app). Now because the user is unauthenticated at this point, we needed some way to return those two specific ids for the client. We have accomplished this using a sub-domain for identification.

Eg acmeinc.mydomain.com will return a different Application (client ID) and Directory (tenant) ID than billy.mydomain.com . These are obviously public now as this request happens from an un-authenticated front-end route.

I can handle the token response just fine, both in the front-end and in the back-end when I pass it along, and validate that these two pieces of information are correct in the token, but seeing as the front-end is given them to begin with, validation on these is redundant. Also, validating the issuer seems equally redundant as someone who knows the Directory (tenant) ID, can fake that too (right?)

Am I missing something here? I would feel far more at ease if it were possible to request the client also include a claim that my platform generates privately such that I could validate this claim alongside the normal JWT validation. Custom claims do not seem possible from the Azure AD Portal.

Am I missing a critical step, or just overthinking this?

Answer 1

Someone cannot fake the issuer in the token because the token is digitally signed. Without the private keys of Azure AD, it isn't feasible to generate a valid signature. Without that, any modifications to the token will be immediately noticed because the signature does not match.

Your back-end should already be validating this signature if you are using standard JWT validation.

Requiring customers to register an app in their tenant is a bit of work that I would prefer not to put on them. Have you considered making your app a multi-tenant app in Azure AD? That way your customers could login to your app, consent to the permissions required, and start using it. Without needing to manually register anything. This could be done in an on-boarding flow where the user signs in, and then they can decide what sub-domain they want. You will at that point know their tenant id, which you can store. So in the future you can always use the correct tenant/directory id when signing them in.

The downside of this approach is managing the reply URLs. With the specially registered apps, they can register their own sub-domain version as a reply URL. With this generic multi-tenant app, you'll need to manage them. And you can't add an infinite amount of them, and wildcards aren't supported anymore either. So, your authentication would have to happen with a generic authentication reply URL like auth.mydomain.com, from which they would be redirected to their tenant URL.