Azure AD - Differentiate between App token and User token

Question

I am building a asp.net webapi which is protected by Azure AD Oauth bearer token authentication. I am using Azure AD Bearer token validation OWIN middle-ware to validate the token and extract the claims.

I have a requirement to differentiate when a request is coming from a service context and when the request coming from user context. I am aware that App Tokens (Issued by AD for a APP context) will not have any UPN claims using which i can easily identify but i was wondering is their any standard way to do this?

Answer 1

There is now a supported way of telling whether or not the token is for an App or not.

Azure Ad supports the configuring of access tokens, for your protected resource to have some optional claims. The claim needed to answer "Is token for App?" is "idtyp"

See Configuring optional claims for how to set it up

Answer 2

Per the Microsoft Docs

Your application may receive tokens on behalf of a user (the usual flow) or directly from an application (through the client credentials flow). These app-only tokens indicate that this call is coming from an application and does not have a user backing it. These tokens are handled largely the same, with some differences:

• App-only tokens will not have a scp claim, and may instead have a roles claim. This is where application permission (as opposed to delegated permissions) will be recorded. For more information about delegated and application permissions, see permission and consent in v1.0 and v2.0.
• Many human-specific claims will be missing, such as name or upn.
• The sub and oid claims will be the same.

Personally in my code, to determine if a token is an App token, I use a combination of checking that the claims: "oid" and "sub" both exist and are the same, as well as checking that the token does not contain a name claim.

In practice I have found that tokens issued using different flows can contain different claims, which is why I have found using a combination of a couple of these properties can lead to better being able to differentiate between a user and application token.

Answer 3

Quoting from an internal forum:

The appidacr claim indicates the type of client authentication performed. For a confidential client, the value is 1 when a shared secret (a password) is used as a client secret and 2 when a certificate is used as a client secret. The value 0 indicates a public client, which does not provide a client secret and therefore does not authenticate to the STS. Since confidential clients can acquire both user delegated and app only access tokens, the appidacr claim alone does not help to distinguish a user token from an app-only token.

If you want to distinguish between app-only access tokens, user-delegated access tokens, and id tokens issued by Azure AD (all of which are JWTs signed by the same key), follow this guidance:

1. First of all, validate the ver claim's value is 1.0.
2. Next, check to see if the JWT is an access token or an id token. The most reliable way to distinguish between the two is the presence of the appid and appidacr claims. These claims will be present in access tokens, but not id tokens.
3. If the JWT is an id token, then it represents a user. The subject of an id token issued by Azure AD is always a user. Never accept an id token as proof of authentication, always require an access token.
4. If the JWT is an access token, the presence of an scp (scope) claim informs you that the token is a user delegated access token. The value of the scp claim tells you what authorization the client has been granted by the user.
5. If the access token does not have an scp claim, it is an app-only access token. In this case, it may have a roles claim.

Don't rely on UPN and email claims to determine the type of token, they're not as reliable.