followed every instruction above for auth token input binding but still having an error in the log saying Error while accessing 'X-MS-TOKEN-AAD-ID-TOKEN'. even after being logged in manually with https://
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@fiyazbinhasan Thanks for the question! We are investigating and will update you shortly.
@mattchenderson can you take a look into this one?
@mattchenderson I no longer having this issue after selecting Login with Azure Active Directory
from the dropdown. But I'm facing this new issue now when I try to trigger the ProfilePhotoAPI template - Input id_token cannot be used as 'urn:ietf:params:oauth:grant-type:jwt-bearer' grant.
This was a change in AAD behavior that we missed, but will go into a future release. In the meantime, the workaround is to set the field oauth2AllowImplicitFlow
in the Application Manifest to true.
@ConnorMcMahon works like a charm! However, the default ProfilePhotoAPI
triggers successfully but showing this error message on the browser,
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "30539517-e62d-466b-9881-0833e6729849",
"date": "2018-05-07T18:36:41"
}
}
}
I checked the xhr in the devtools; it says unauthorized 401
!
Can you double check that your AAD application has the appropriate permissions. For this example it should be "Sign in and read user profile" under the application "Windows Azure Active Directory".
Yes. It does have that permission checked.
@ConnorMcMahon Maybe it's some sort of authentication/permission issue with the photo API, https://graph.microsoft.com/v1.0/me/photo/$value. The me
API works great https://graph.microsoft.com/v1.0/me/ on the other hand. Closing this issue as of now.
@ConnorMcMahon Sorry to comment on an already closed issue, recently I am still facing the error AADSTS240002: Input id_token cannot be used as 'urn:ietf:params:oauth:grant-type:jwt-bearer' grant
when keeping the oauth2AllowImplicitFlow
with default value false
. Requested scopes are openid, https://graph.microsoft.com/user.read
.
About the workaround is to set the field oauth2AllowImplicitFlow in the Application Manifest to true
from your comment, is that still a must or it can be some other issue in my configuration? Thanks.
setting up oauth2AllowImplicitFlow in the Application Manifest to true WORKED !! Thanks
Hi all, I'm facing with the same issue, AADSTS240002: Input id_token cannot be used as 'urn:ietf:params:oauth:grant-type:jwt-bearer' in case of "On Behalf Of" scenario, do you have any idea how this problem could be resolved? Many thanks. oauth2AllowImplicitFlow already set to "true".
Removing wildcards in Reply URLs fixed the issue for me
This was a change in AAD behavior that we missed, but will go into a future release. In the meantime, the workaround is to set the field
oauth2AllowImplicitFlow
in the Application Manifest totrue.
@ConnorMcMahon Is there an issue we can follow or other way of being notified when this workaround won't be needed? I may be misunderstanding something, but changing an app's authorization flow to implicit when it could/should be using auth codes seems to have security implications and I don't think I'm comfortable with using it long-term if I don't have to. There seems to be a lot of advice against using implicit grants at all, let alone when the use case doesn't demand it for technical reasons.
@ConnorMcMahon - looping back to this:
Is https://github.com/microsoft/azure-spring-boot/issues/333 the representative issue for tracking this? Like @lhanson mentioned, being required to use implicit flow over authorization code flow is not an optimal (or secure) pattern.
Alternatively, are there other/better workarounds to this problem?
Edit/Update
Reviewing the calls made during the auth flow, it does look like we're in the auth code flow (GET /authorize with response type of code, POST to token, GET of keys). So, I'm curious about what's in play here by way of enabling the implicit flow in the app manifest.
hi, Implicit grant is not be allowed in my security policy. Is there any other workaround or plan to fix this issue?
Take a look in Authentication code with PXCE. It can be useful if you are dealing with authentication for SPAs.
Most helpful comment
@ConnorMcMahon Is there an issue we can follow or other way of being notified when this workaround won't be needed? I may be misunderstanding something, but changing an app's authorization flow to implicit when it could/should be using auth codes seems to have security implications and I don't think I'm comfortable with using it long-term if I don't have to. There seems to be a lot of advice against using implicit grants at all, let alone when the use case doesn't demand it for technical reasons.