I'm moving our existing Office365 API usage over to the Unified API (at https://graph.microsoft.com/v1.0).
For reasons explained in Adding an additional Windows Azure AD delegated permission to an existing grant, I need to include prompt=consent in my authorization request Url, and so up until now my authorization Url has looked like:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3a%2f%2fgraph.windows.net%2f&prompt=consent&client_id=ec49c780-6767-46f2-8697-bdd816e42504&redirect_uri=https%3a%2f%2flogin.airhead.io%2fservices%2freply%2foffice365%2foauth&scope=UserProfile.Read+Calendars.Read+Files.Read+Sites.Read.All+Mail.Read&response_type=code
..which (after auth and consent) returns me to something like:
https://login.airhead.io/services/reply/office365/oauth?code=AAABAAAAiL9Kn2Z27UubvWFPbm0gLeSvP6UG3gEwceCQ8hU_03hUjXRvPUfs_Y-324csuR0rDFE-qdNIsD0on-DjKGoSzvVL4PKh7_uQkghxtOGCZGEJ7GwcUDpvoHH86pjct3vAb94wPt8Pkdm46HhvPeBn6JDrK5VIBYdwxS2r8dLRmjqiyIBbGZDsOUCDymeFebYsFc-V39sQ9WFSx5ErjIeHvZ_Qf4zB1SDjT-iEqJPTW7H5bZpvFJQHhUqn3TvVL37Up4ZzkWxz5fb0zMk_7yKuz6G-DW6kz_Y1S30ZNgO45maDEw9KBqmdIR_NeewmFSKokgF4Unsfi__xNzjf6xO6VcMOidych7V7uQi_jxX7zP5hLvXgAoNmqBU-AnV2NVZ-5tq2s4w8vvl61TXUjR1MtwVf4TzcsL55uvyP16lid6JpWsdssZvWJNXna_zJC0Ok629vE5-4pzu-zF5C_PJztkx8VQ8QDmP4_JqkHkRmq2zO0doY25AF6Sh3odyNEx6IwWxe9jirPv_8NfwlmldYnpItzbmYlqLilOIEBNXpESgUmPz02A0Czu--pZP45JfjNDrVnUBBV9liPToK_QPe99xOSNHmk70h171M5BjVnhggAA&session_state=8494e152-60ab-4ddc-a247-ee55798e0595
..which allows me to continue with the flow, using the code auth'd against the old https://graph.windows.net/ resource. All good.
However, after modifying the resource param value on the authorization Url to https://graph.microsoft.com/ to authorize against the new Unified API, i.e.:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3a%2f%2fgraph.microsoft.com%2f&prompt=consent&client_id=ec49c780-6767-46f2-8697-bdd816e42504&redirect_uri=https%3a%2f%2flogin.airhead.io%2fservices%2freply%2foffice365%2foauth&scope=UserProfile.Read+Calendars.Read+Files.Read+Sites.Read.All+Mail.Read&response_type=code
..I'm returned an error response:
https://login.airhead.io/services/reply/office365/oauth?error=access_denied&error_description=AADSTS65005%3a+The+client+application+has+requested+access+to+resource+%27https%3a%2f%2fgraph.microsoft.com%2f%27.+This+request+has+failed+because+the+client+has+not+specified+this+resource+in+its+requiredResourceAccess+list.%0D%0ATrace+ID%3a+d9cc9773-feb5-42b4-9414-eaf64620fc0f%0D%0ACorrelation+ID%3a+ea1f37de-35bb-4b41-af49-c877dda75d11%0D%0ATimestamp%3a+2016-01-18+13%3a15%3a18Z
..with description "AADSTS65005: The client application has requested access to resource 'https://graph.microsoft.com/'. This request has failed because the client has not specified this resource in its requiredResourceAccess list".
If I try the same authorization Url (against resource https://graph.microsoft.com/ again), but drop the prompt=consent param this time, i.e:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3a%2f%2fgraph.microsoft.com%2f&client_id=ec49c780-6767-46f2-8697-bdd816e42504&redirect_uri=https%3a%2f%2flogin.airhead.io%2fservices%2freply%2foffice365%2foauth&scope=UserProfile.Read+Calendars.Read+Files.Read+Sites.Read.All+Mail.Read&response_type=code
..it works.
The documentation at https://msdn.microsoft.com/en-US/library/azure/dn645542.aspx still suggests that prompt=consent is valid, so is the documentation wrong (i.e. I can't use prompt=consent with resource https://graph.microsoft.com/) or is this a bug?
It turns out there's a whole new set of scopes for v1.0 of graph.microsoft.com, which weren't needed during the preview. Adding these scopes to my app manifest resolved the issue. (facepalm)
Related
We're implementing a custom identity provider for Azure AD B2C, using OpenID protocol option, as a generic OpenID Connect.
Everything works as expected until it's time to post the response back to Azure AD B2C using the redirect URI provided. I've found documentation regarding expected structure of this response URL, and what we see in the documentation is identical to what Azure AD B2C specifies when it issues the authentication sequence.
Configured values:
Response type: code
Response mode: form_post
User ID claim: sub
Display name claim: name
When the custom identity provider GETs or POSTs authentication response (code) back to https://REDACTED.b2clogin.com/REDACTED.onmicrosoft.com/oauth2/authresp, the Azure B2C returns 404.
Note that this is not 400, not 401, not 403, not 5xx. It is precisely 404 (not found), with a basic text (non-html) content saying resource not found. This response looks to me very much like a misconfigured API management layer on Azure side, hitting a wrong internal URL.
We're expecting that the URL https://REDACTED.b2clogin.com/REDACTED.onmicrosoft.com/oauth2/authresp actually works. It looks like what the expected Azure AD B2C response endpoint is from documentation, and it is also exactly what Azure AD B2C itself specifies when initiating the OpenID sequence with our custom identity provider web application.
So far we were unable to find the root cause, nor even any useful input beyond raw network request logs (case with Microsoft support was open since 2023-01-23). The last resort could be re-creating the B2C tenant, since this feature seems to work for other people, but that would require migration and significant down time on our end.
SOLUTION: The response to AD B2C authresp endpoint was missing 'nonce' claim (in the id_token payload), and 'state' parameter in the HTTP request. Both values are supplied by AD B2C when initiating authorization. As soon as custom identity provider started properly adding those two values, error 404 went away.
Response should include supplied nonce as a claim inside the id_token payload, and supplied state as HTTP request parameter or query string
https://openid.net/specs/openid-connect-basic-1_0.html
I had the same issue (a 404 error as a result of the /authresp POST from my custom OIDC IdP back to Azure AD B2C using the redirect URI Azure AD B2C had just provided as a query parameter on the /authorize request to my IdP: redirect_uri=https://mytenant.b2login.com/mytenant.onmicrosoft.com/oauth2/authresp
In my case (using an implicit flow), it was about properly handling the "nonce" query parameter on the inbound /authorize request (from Azure AD B2C to my IdP) by ensuring the generated id_token it returned included the nonce as a claim.
In your case (using an authorization code flow...and assuming you also return an id_token based on the "sub" and "name" claims you're returning), your /token endpoint needs to include the nonce inside the id_token...so propagate the nonce (and state) as query parameters along to your /token endpoint via the /authorize to /token redirect method you use.
If a federated IdP doesn't include the nonce as a claim inside the id_token payload that it returns, Azure AD B2C will return a 404 error from the /authresp request.
I don't know why Microsoft chose to return a 404 instead of a more informative "nonce invalid" error message, or at least, a 400 error...perhaps it's for the same security reason a login form doesn't precisely tell you when your password is invalid.
In the OpenID Connect specification, the nonce description (under IDToken) states (bolding is my doing):
String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used. The nonce value is a case sensitive string.
Although the spec indicates a nonce is optional, Microsoft is following best practices by supplying one...and since Azure AD B2C (as the Authorization Server) gets the id_token from the IdP, it requires a federated OIDC IdP to play by the same rule.
In case this helps others, my custom IdP's /.well-known/openid-configuration endpoint returns:
{
"authorization_endpoint": "https://myidp.azurewebsites.net/oauth2/authorize",
"authorization_response_iss_parameter_supported": true,
"claims_parameter_supported": false,
"claims_supported": [
"aud",
"idp",
"iss",
"iat",
"exp",
"nonce",
"s-hash",
"sid",
"sub",
"auth_time",
"email",
"family_name",
"given_name",
"locale",
"name",
"updated_at",
"user_id"
],
"claim_types_supported": ["normal"],
"grant_types_supported": ["implicit"],
"id_token_signing_alg_values_supported": ["RS256"],
"issuer": "https://myidp.azurewebsites.net",
"jwks_uri": "https://myidp.azurewebsites.net/oauth2/jwks",
"response_modes_supported": ["form_post"],
"response_types_supported": ["id_token"],
"scopes_supported": ["openid"]
}
(Yes, my IdP runs on an Azure App server...but, "myidp" isn't my real tenant name.)
p.s. Currently, my IdP is used exclusively in a federation with AzureAD B2C (which acts as the Authorization Server for my client application via the MSAL library), so my IdP simply supports just an implicit flow and three endpoints (/.well-known/openid-configuration, /jwks and /authorize). If it were a general purpose IdP, or allowed direct client requests, it would support other flows (e.g. an authorization code flow), additional scopes (beyond "openid"...e.g. "profile") and additional endpoints (e.g. /token and /userinfo). However, regardless of flow, as long as an id_token is returned, it needs to include the nonce in its payload.
To troubleshoot the issue, I would recommend the following steps:
Verify that the redirect URI you are using is correct and matches
the one specified by Azure AD B2C.
Check that the response type and response mode specified in your
custom identity provider match the values expected by Azure AD B2C.
Verify that the claims you are sending in the response (e.g. "sub"
and "name") match the expected format and values for Azure AD B2C.
Check the network request logs for any additional information that
might help identify the issue.
If possible, try to isolate the issue by testing the authentication
flow with a minimal configuration to determine if the problem is
with your custom identity provider or with Azure AD B2C.
If the issue persists after trying these steps, you may want to consider reaching out to Microsoft support for further assistance.
I tried to reproduce the scenario in my environment:
Make sure the endpoint to which I requested the authorization url
It includes policy and with
redirect URI= https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/authresp
User Flow is of SignupSignin and not just Signin
Make sure to include all the required api permissions , importantly make sure to include openid , profile
I Configure idp such that , userId is mapped to oid.
The authorization url must have the policy included .
Here I have B2C_1_SignupSignin policy set for the User flow.
redirect URI= https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/authresp
Auth url:
https://kavyasarabojub2c.b2clogin.com/kavyasarabojub2c.onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_newSignupSignin&client_id=xxx&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fxxxb2c.b2clogin.com%2Fxxxb2c.onmicrosoft.com%2Foauth2%2Fauthresp&scope=openid&response_type=id_token&prompt=login
When profile scope is not given I got bad request
But when openid and profile along with Directory.Read.All api permissions are included, the request run successfully.
Note: metadata url must be : https://login.microsoftonline.com/<tenantId>/v2.0/.well-known/openid-configuration
Successfully logged in and got the token containing idp_access_token
Identity provider access token , decoded and got the user claims:
I've followed this guide to configure access to my backend app, but I use Node backend and React frontend. However I'm unable to perform the step Configure App Service to return a usable access token. I get the error "Cannot execute the request for site x because the site is running on auth version v2.". To handle this I tried instead editing the sheet authsettingsV2, and I believe I found that the property properties.identityProviders.azureActiveDirectory.login.loginParameters in v2 equals properties.additionalLoginParams in v1 as editing this v2 property according to the tutorial shows the desired property in the v1 authsettings sheet.
However accessing my frontend app with this setting I get the error AADSTS901002: The 'resource' request parameter is not supported. before even being able to enter my credentials.
I've also tried without the additionalLoginParams setting completely, this gives me the error {"code":401,"message":"IDX10511: Signature validation failed. Keys tried: '[PII is hidden]'. \nkid: '[PII is hidden]'. \nExceptions caught:\n '[PII is hidden]'.\ntoken: '[PII is hidden]'."} on the API call, and upon inspecting my token, I find that the audience is the Microsoft Graph API. But I guess that is expected with this setup.
How can I proceed to enable access to my backend app? / How do I set the additionalLoginParams in auth version v2?
I am not sure if you have a correct access token. Please note that I am not talking about id token. Because from your response_type=code id_token, there should be only one id_token returned, but obviously the id_token cannot call your api, because what you need is an access token.
If you have not obtained a correct access token, then you should request an access token in the next step, refer to this link.
In addition, I must explain that all 401 errors are caused by api audiences. Therefore, make sure that your Application ID URI is set in the scope parameter.
When requesting an access token, you need to set the scope to: scope=openid api://{back-end api client id}/.default. Set response_type to: response_type=token.
I am attempting to access the SharePoint Online REST API (this is hand coded REST calls, no library being used).
Access tokens are acquired using authorization grant flow as follows:
I send the browser https://login.microsoftonline.com/common/oauth2/authorize?...
This redirects to a handler endpoint that we extract the access code from
I obtain the tenant ID by:
GET https://{tenantname}.sharepoint.com/_vti_bin/client.svc
Then extracting the tenant ID from the WWW-Authenticate header
I then POST https://login.microsoftonline.com/{tenantid}/oauth2/authorize to obtain the access token
When I use that access token, I am able to do queries using:
GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=....
This works and returns documents.
But when I attempt to retrieve information about one of those documents:
GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I get a 404 response with the following body:
{"odata.error":{"code":"-2130575338, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"The file /TestFiles/test.pdf does not exist."}}}
If I navigate to the URL in a browser (https://{tenantname}.sharepoint.com/TestFiles/test.pdf), it accesses the file without issue.
This makes me think that I'm running into some sort of permission issue.
I have tried setting the following scopes in the authorize redirect:
Attempt 1: scope = Web.Write AllSites.Write Site.Write
Attempt 2: scope = https://{tenantname}.sharepoint.com/.default
Attempt 3: scope = https://{tenantname}.sharepoint.com/Web.Write https://{tenantname}.sharepoint.com/AllSites.Write https://{tenantname}.sharepoint.com/Site.Write
No matter what I set as the scope parameter of the authorize URL, the JWT details of the access token show (I can post the entire decoded JWT if anyone needs it):
"scp": "User.Read"
Nothing I do has any impact on the scp in the token - I have no idea if that's the issue or not. If it is, I would appreciate hearing how to properly request scope.
The application registration in Azure Active Directory has desired permissions (plus more):
What am I doing wrong?
UPDATE: Switching to OAuth endpoint v2.0:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
With query parameters:
response_type = code
client_id = my app id
redirect_uri = my redirect uri
scope = <varying - I'll explain what happens under different scenarios below>
Here's what I've tried for scopes:
AllSites.Write Site.Write - the redirect has invalid_client with error_description = AADSTS650053: The application '' asked for scope 'AllSites.Write' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/AllSites.Write https://.sharepoint.com/Site.Write - the redirect has invalid_client with error description = AADSTS650053: The application '' asked for scope 'Site.Write' that doesn't exist on the resource '00000003-0000-0ff1-ce00-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/.default - this goes through
But the resulting JWT has only scp=User.Read
The following works: GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=
But the following returns a 404: GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I don't understand how Scope=.Default isn't including the allowed permissions from the application registration. And I definitely don't understand why the AllSites.Write scope is failing when it's explicitly specified.
If it helps, I have also tried all of the above using a tenant specific authorize endpoint instead of 'common':
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize
UPDATE2: More scope changes:
I finally found a magical combination that works:
Use a tenant based URI for the /authorize and /token endpoint and use {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following:
"scp": "AllSites.Write User.Read"
I am completely perplexed about why Site.Write wasn't allowed. I suppose that AllSites.Write is a superset of Site.Write, so maybe not needed?
All of my testing so far has been on my own tenant, next step is to test on a different tenant and make sure it actually works there as well.
It seems you use v1.0 endpoint https://login.microsoftonline.com/common/oauth2/authorize but not v2.0 endpoint https://login.microsoftonline.com/common/oauth2/v2.0/authorize. If we use v1.0 endpoint, we should use resource instead of scope. So that is why the scp claim in your access token always the same no matter you modify the scope.
You should use resource with https://{tenant-name}.sharepoint.com and the parameter scope is useless when you use v1.0 endpoint.
If you still want to use scope parameter, you can also change the endpoint to v2.0. Just add v2.0 into your endpoint, like: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
I finally found a magical combination that works:
use the https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize and https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/token endpoints
specify {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope - that was the primary problem):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following: "scp": "AllSites.Write User.Read"
This works across tenants and gets us the access we need.
For thoroughness, we also specify offline_access scope so we get a refresh_token in addition to the access_token.
I am trying to obtain an access token for use with the SharePoint Rest API. For my organizations base site. I am able to obtain a token and use that token to make subsequent requests successfully.
Next, I followed the same process and created more app permissions for a different site: {{tenant removed}}/sites/testsite. I was initially unable to create the request for the token because the resource parameter was not valid (see image below):
Per the URI encoding standards, I replaced the "/" in the site url with "%2f" and I am able to get a token (see image below):
Next however, the requests using that token to the API fail:
{
"error_description":
"Exception of type 'Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException' was thrown."
}
In the response header:
3000003;reason="Invalid audience Uri
'00000003-0000-0ff1-ce00-000000000000/{{tenant
removed}}%2fsites%2f{{removed}}#{{realm
removed}}'.";category="invalid_client"
Did I encode the resource incorrectly? What am I missing? How can I use this method to get information from the other site?
I can see many developers making the same assumption when they create requests, since almost all documentation don't point out this scenario. You will be able to obtain a token for the site successfully as long as the resource is in a valid uri format, there is no validation done on the uri itself. Even if you get a token it will not work for any requests.
When fetching the access token for subsites (i.e: {{tenant}}/sites/testsite ). The resource part of the request body does not need to be modified.
So, for example, when you are getting a token for test.sharepoint.com/sites/testsite the resource of the request body should just be:
00000003-0000-0ff1-ce00-000000000000/test.sharepoint.com#{{realm}} (without /sites/testsite)
However, when you make HTTP requests to the API with the token, you should use the full site name. Example:
https://test.sharepoint.com/sites/testsite/_api/web/
I have a backend process that doesn't directly interact with the user. I want to access reservations associated with my Azure account but I'm having trouble with the authentication step. I was following the guide here and I managed to get the authentication request to work by calling
https://login.microsoftonline.com/{tenant-ID}/oauth2/token
as a POST with the following x-www-form-urlencoded body:
grant_type=client_credentials&
client_id={client-ID}&
client_secret={client-Secret}&
resource=http://myapp42
However, when I attempt to call:
https://management.azure.com/providers/Microsoft.Capacity/reservationOrders/{order-ID}/reservations/{reservation-ID}?api-version=2019-04-01
with the bearer token I received during the authentication step, I get the following error message:
The access token has been obtained for wrong audience or resource 'http://myapp42'. It should exactly match with one of the allowed audiences 'https://management.core.windows.net/', 'https://management.core.windows.net', 'https://management.azure.com/', 'https://management.azure.com'
However, if I modify the resource on the request to be one of these, http://management.core.windows.net/ for instance, the authentication then fails with:
AADSTS500011: The resource principal named https%3A%2F%2Fmanagement.core.windows.net%2F was not found in the tenant named {tenant-ID}. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.\r\nTrace ID: b54cedea-3804-41cf-bd27-fcf0ed1c4700\r\nCorrelation ID: 2371d375-6c89-4f05-83c9-c4629b3340a8\r\nTimestamp: 2020-02-05 01:59:57Z
How do I authenticate so that I can then get my reservations without having to login?
Update:
The service principal has both the Owner and Contributor roles assigned.
Update 2:
Thanks to #Jim Xu, I was realized that I needed to refrain from url-encoding the URL. That allowed me to get the access token with a value of https://management.azure.com/ for the resource field. However, at this point, when I attempt to call the REST API with the resulting bearer token, I get the following error:
The client '{Object-ID}' with object id '{Object-ID}' does not have authorization to perform action 'Microsoft.Capacity/reservationOrders/reservations/read' over scope '/providers/Microsoft.Capacity/reservationOrders/{order-ID}/reservations/{reservation-ID}' or the scope is invalid. If access was recently granted, please refresh your credentials
Note: The object ID returned by this error is the one associated with the service principal.
Update 3:
I checked the reservation and it seems that the principal does not have a role in that reservation's access control. However, I also cannot assign the principal a role because it does not show when I search for principals during the role-assigning process.
If you want to call Azure Rest API to get the information of reservation Orders, you need to assign Owner\Contributor for the service principal.(the action needs Microsoft.Capacity/reservationOrders/read permission).
The steps are as below
Get access token
POST : https://login.microsoftonline.com/{tenant-ID}/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&
client_id={client-ID}&
client_secret={client-Secret}&
resource=https://management.azure.com/ or https://management.core.windows.net
Call the api
GET : https://management.azure.com/providers/Microsoft.Capacity/reservationOrders/{order-ID}/reservations/{reservation-ID}?api-version=2019-04-01
Authorization: Bearer <token>
For more details, please refer to the issue and the issue
update
If you have assigned role but you still cannot get access token, please try to encode your url.