- last edited on
while developing an application that relies on Azure AD for authentication, I found out what seems to be an issue with v2.0 endpoints.
TL;DR: When requesting a Bearer Token using an authorization code v1.0 endpoints work fine, but v2.0 endpoints keep saying that "the user or administrator has not consented to use the application ID ..." even if the consent happened in the very same session.
In more details: in my application, an nw.js app leveraging the chrome.identity API, I call Azure AD oauth2 authorization and token endpoint directly via HTTP requests.
Initalliy I make a GET request an authorization code to the endpoint https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize?response_type=code&... and the code is returned correctly.
After this first step I try to use this code to retrieve a Bearer token sending a POST request to the endpoint https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token with grant_type=code&... and all the needed parameters in the request body.
Here is where I can see that by using the v1.0 token endpoint I recieve back a valid Bearer Token, while pointing to the v2.0 token endpoint I always recieve the AADSTS65001, suberror: "consent_required".
I tried many solution to get the token from the v2.0 including:
- granting consent via App registration panel, in azure portal
- using the adminconsent endpoint to grant permission
- using the "prompt=consent" request parameter to explicitly ask the user (me) consent everytime, both ticking and leaving unticked the "Consent on behalf of the organization" option
to no avail...
Everytime the authentication flow seems to be completing correctly but it always replies I need to give consent, even when I just did.
Before giving up I tried using the v1.0 endpoint, and that's how I noticed this issue.
This actually didn't happen in a previous test I did using this method: in that test I was using an Azure subscription registered with a Microsoft Live account, and that didn't give any problem. Now that I switched to use the Azure subscription that pertains to the organization Azure AD (the one used to manage Office 365 accounts), this problem happend. Even though I am global administrator in both situation.
Know I don't know if it's the v1.0 endpoint that's operating properly or the other way around, either way I found this inconsistent behavior between the two version and though it was useful to point out.
I am available to give more details, or to discuss this further if it may help.
If you feel there is a more suitable place to post this type of questions, please do point out.
08-31-2019 09:32 AMSolution
As per the details that you have mentioned,
Grant_type is the parameter used for V1.0 Endpoints,
For v2.0, add scope in the initial request of requesting code,
Let me know, if still it doesn't work.
09-01-2019 02:39 AM - edited 09-01-2019 02:45 AM
thank you very much for your quick reply, and for pointing me in the right direction.
Turns out it was, as expected, a mistake on my part: as I had all scopes set up correctly in the 1st request, but in the 2nd, the one that exchanges the code for the token, I was attempting to pass the scopes as comma separeted values instead of encoding them properly as URL encoded space separated values.
I speculate this let the auth server think I was requesting scopes that didn't actually exist, and therefore, for which no user or admin ever gave permission to use.
This should also explain why the v1.0 endpoint works, as the documentation says "For v1 Azure AD apps, scopes must be statically configured in the Azure Portal under the applications Settings, Required Permissions." and this parameter was in fact being ignored.
Now everything seems to be working as expected.
Thank you again for your time and interest, your contribution was of great help.