Search code examples
tokenazure-active-directoryazure-authentication

how do azure ad provider validate token and user access permission to the applications?


when using AZURE AD for authentication we get a token for a successful login which we pass to the resource server or api controller.

In my case I have 4 applications in my directory WebApp1, WebApp2 ,ApiApp1, ApiApp2 & 2 users - user1 & user2

All the users are assigned to all applications.

But only WebApp1 has permission to ApiApp1 & ApiApp2 , WebApp2 has permission to ApiApp2 only.

My question here is how do the AAD provider at applcation end validate the user token and permissions?

When I observe using fiddler I dont see any calls being made to the authority (AAD) for validating the token and app permissions?

How does the AAD provider at application end make sure it is issued by a valid AAD and the user has permission to the application ?

In case it is a API app how does the AAD provider make sure that the app to which the token is issued has permission to the web app?


Solution

  • So there are multiple questions here so I'll try to answer all of them as best I can.

    The applications only check the tokens are signed with the correct keys by verifying their digital signature. Typically there would be one call to the authority to get the signing public keys when the app starts. If you can't see one, it's either because Fiddler can't see it or because the library in question is not validating the token(!). In case of an app I have that uses the OWIN OpenId Connect middleware, I can see a call to https://login.microsoftonline.com/tenant-id/.well-known/openid-configuration, and then https://login.microsoftonline.com/common/discovery/keys, which is where the signing public keys are.

    The user's permission to the app are in their claims. When you add a delegated/app permission to an app, you always define a value. These values are sent in the token. App permissions are in a claim called roles (IIRC), and delegated are in scp. Azure AD will only put the claims there for the permissions given to each app/user. Your app trusts AAD to do the correct thing (and verifies with the signature it was indeed AAD).

    That goes for both Web and API apps actually. If you try to sign in to the front-end app through Authorization Code Grant Flow for example, the user will get an error message that they are not allowed to access the app. AAD will not send an authorization code/id token back for this user. If you got one, they are fine.

    Your WebApp1 cannot call ApiApp2 because AAD will not give it an access token to it.