Azure AD access token verification fails on Apigee

Hi

I am testing Apigee and Azure AD integration. Want to validate azure AD access token from Apigee but the verify access token policy fails. However, if i pass IDToken to that policy wth no other change, it passes.

The only error i get is "Invalid token" from policy. Has anyone faced any such issue.

{ "header": { "typ": "JWT", "nonce": "PniTLGqCL3xfgeoqMV1zVkM5J-Xjtam8WBTxBHFSMl0", "alg": "RS256", "x5t": "XXXX", "kid": "XXXX" }, "payload": { "aud": "https://graph.microsoft.com", "iss": "https://sts.windows.net/XXXX/", "iat": 1588924846, "nbf": 1588924846, "exp": 1588928746, "aio": "42dgYFiiJrf7N8MMA9cPF/NeSJnMBwA=", "app_displayname": "apigee", "appid": "XXXX", "appidacr": "1", "idp": "https://sts.windows.net/XXX/", "oid": "2d2299b3-0316-44a2-9c43-0f6a3ecf4b9c", "sub": "2d2299b3-0316-44a2-9c43-0f6a3ecf4b9c", "tid": "805bc75c-ff3e-49fa-84a9-57d593c3d212", "uti": "yv39u80DrkuioMCmaegMAA", "ver": "1.0", "xms_tcdt": 1587993062 } }

Solved Solved
1 3 1,970
1 ACCEPTED SOLUTION

Yes, I can help you.

First, you are not alone! Many people have confronted the problem you are seeing. It is not a problem in Apigee.

Second, that thing you showed... is not a JWT. It looks like a JWT! It seems like a JWT. The structure of it leads you to believe strongly that it is a JWT. But, it is not a JWT, because it cannot be validated according to the IETF spec for JWT. Not by Apigee, not by any JWT library or toolkit.

In the discussion thread on github.com, Brent Schmaltz from Microsoft stated that this thing-that-looks-like-a-JWT is just an access token, and that it's intended for use by MS Graph, and also reminded everyone that there's no requirement that the access token be a JWT.

What he did not say is this: "When Azure AD issues a token that is not a JWT, but looks very much like a JWT, it causes confusion."

Last, if you want to get a token from Azure AD , which is a JWT, and can be verified independently, then, using the Azure AD administration panels, you must go to your application page, and in the "Scopes" menu entry, specify a scope for the application. Then, when you request the token, you must request that scope.

The thing you get back will be a valid JWT that can be verified by anyone, including the Apigee policy.

If instead, when requesting the token, you use scopes like "User.read", "openid", "profile", "email", ... You'll see that the aud claim in the returned access token will be set to https://graph.microsoft.com. That indicates that the token (this thing that is NOT a JWT, but looks like one) is intended for consumption by the Microsoft AD graph, and it is not intended for consumption by your application. It will not be verifiable.

More reading on the topic.

View solution in original post

3 REPLIES 3

Yes, I can help you.

First, you are not alone! Many people have confronted the problem you are seeing. It is not a problem in Apigee.

Second, that thing you showed... is not a JWT. It looks like a JWT! It seems like a JWT. The structure of it leads you to believe strongly that it is a JWT. But, it is not a JWT, because it cannot be validated according to the IETF spec for JWT. Not by Apigee, not by any JWT library or toolkit.

In the discussion thread on github.com, Brent Schmaltz from Microsoft stated that this thing-that-looks-like-a-JWT is just an access token, and that it's intended for use by MS Graph, and also reminded everyone that there's no requirement that the access token be a JWT.

What he did not say is this: "When Azure AD issues a token that is not a JWT, but looks very much like a JWT, it causes confusion."

Last, if you want to get a token from Azure AD , which is a JWT, and can be verified independently, then, using the Azure AD administration panels, you must go to your application page, and in the "Scopes" menu entry, specify a scope for the application. Then, when you request the token, you must request that scope.

The thing you get back will be a valid JWT that can be verified by anyone, including the Apigee policy.

If instead, when requesting the token, you use scopes like "User.read", "openid", "profile", "email", ... You'll see that the aud claim in the returned access token will be set to https://graph.microsoft.com. That indicates that the token (this thing that is NOT a JWT, but looks like one) is intended for consumption by the Microsoft AD graph, and it is not intended for consumption by your application. It will not be verifiable.

More reading on the topic.

Thanks Dino. Following this, I am able to validate token now. But scope is not coming in response if i use my custom scope. Any leeds on how to handle this

Are you saying that the Azure token dispensary is giving you a token with a scope you don't expect?

I don't have any good ideas on that. I'm not an expert on the Azure AD token dispensary. You might try the Microsoft forums if that is the topic that interests you.