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 am attempting to use the MSAL python library to call another custom api in Azure(Exposed through AppRegistration with an API scope exposed).
I am writing a daemon application that will make the request.
Following Azure documentation here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-configuration?tabs=python
The last example on this Azure docs suggests you can add assertions about custom claims such as client_ip that would be returned in the token.
Similarly, I would like the preferred_username claim to be set to Test as an example:
app = msal.ConfidentialClientApplication(
config["client_id"], authority=config["authority"],
client_credential={"thumbprint": config["thumbprint"], "private_key": open(
config['private_key_file']).read()},
client_claims={"preferred_username": "Test"}
)
However, When I acquire the token using the following code, the preferred_username claim is not within the Token.
result = app.acquire_token_for_client(scopes=config["scope"])
Within the app registration for the daemon app I have added preferred_username as an optional claim (for access tokens).
I am not sure what is wrong with my approach or if I have misinterpreted the intent of client_claims?
I tried to reproduce the same in my environment and got the results like below:
I created an Azure AD Application and configured custom preferred_username claim:
I generated the token via Postman by using below parameters:
https://login.microsoftonline.com/TenantID/oauth2/v2.0/token
client_id:ClientID
client_secret:ClientSecret
scope:https://graph.microsoft.com/.default
grant_type:client_credentials
Optional claims are not included in the token like below:
Note that: Getting optional claim is only possible with Authorization code flow, ROPC flow, Implicit flow. Currently, Client Credentials flow does not support adding any additional custom claims.
Client Credentials flow fetch the token in the application's context and won't have any user-related claims like preferred_username, given_name or email, etc. So, you have to generate the token in the user's context to get the claims.
Alternatively, I generated the Access Token using the endpoint like below:
https://login.microsoftonline.com/tenantID/oauth2/v2.0/authorize?client_id=ClientID&response_type=token&redirect_uri=redirecturi&scope=user.read&response_mode=fragment&state=12345&nonce=678910
Optional claims are included in the token like below:
Reference:
Client assertions (MSAL) - Microsoft Entra | Microsoft Learn
When using the MSAL library to generate access token for a background console application, using client_credentials, to call two REST endpoints, the get token call is created as:
client_id=XXX&client_info=1&client_secret=XXXX&scope=api%3A%2F%2FMyService-DevBlr-ClientServices%2F.default+api%3A%2F%2FMyService-DevBlr-CoreServices%2F.default&grant_type=client_credentials
and posted to
https://login.microsoftonline.com/a1326aec-378e-4433-8e2a-67a086554fc8/oauth2/v2.0/token
The response is a 400 error:
{"error":"invalid_scope","error_description":"AADSTS70011: The provided request must include a 'scope' input parameter. The provided value for the input parameter 'scope' is not valid. The scope api://MyService-DevBlr-ClientServices/.default api://MyService-DevBlr-CoreServices/.default is not valid.\r\nTrace ID: 203ad632-5e7c-4e61-9dcd-185eb9b49200\r\nCorrelation ID: 99fd979a-2c11-485b-ba14-c0cad3312e02\r\nTimestamp: 2020-01-11 08:36:29Z","error_codes":[70011],"timestamp":"2020-01-11 08:36:29Z","trace_id":"203ad632-5e7c-4e61-9dcd-185eb9b49200","correlation_id":"99fd979a-2c11-485b-ba14-c0cad3312e02"}
When individual scopes are passed in, the call works ok:
Request:
client_id=XXXX&client_info=1&client_secret=XXXX&scope=api%3A%2F%2FMyService-DevBlr-CoreServices%2F.default&grant_type=client_credentials
Response:
{"token_type":"Bearer","expires_in":3599,"ext_expires_in":3599,"access_token":"eyJ0e..."}
and
Request:
client_id=XXXX&client_info=1&client_secret=XXXX&scope=api%3A%2F%2FMyService-DevBlr-ClientServices%2F.default&grant_type=client_credentials
Response:
{"token_type":"Bearer","expires_in":3599,"ext_expires_in":3599,"access_token":"eyJ0eX..."}
The documentation and the API supports scopes array:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Client-credential-flows#code-snippet
There is benefit in getting a single token to be used with multiple service calls, but I can't seem to get this working. Any suggestion is appreciated.
When you acquire an access token, you can only specify scopes for one API.
It seems to me you are trying to acquire a token with permissions to 2 APIs.
This is not possible.
An access token always only contains permissions to one API.
So you must request them separately.
This is due to a token having an audience (aud) claim that identifies the API it is meant for.
It cannot have two values.
In this article https://learn.microsoft.com/en-us/rest/api/resources/tenants/list I can get all the Tenants in my account. Now I want to get all the Organization in devops/vsts in each tenant or directory. Currently Im using this article https://learn.microsoft.com/en-us/rest/api/azure/devops/account/accounts/list?view=azure-devops-rest-5.0 and the token I get in the tenants is not working in getting all the organizations. Is theres a way to list all the organization in each tenant in my account? Thanks!
You can get the list via the below azure API call:
GET https://management.azure.com/tenants?api-version=2016-06-01
And for this API call to returns results correctly you need to gain access token and put it in the request header like that:
Authorization: Bearer access_token
And as shown in the documentation, you can gain the access_token from the below Identity end point as it's Implicit flow token:
Authorization URL: https://login.microsoftonline.com/common/oauth2/authorize
So the steps will be:
1- First make a call to:
https://login.microsoftonline.com/common/oauth2/authorize
With the appropriate parameters like the client_id and etc.
2- Gain access_token from the first step response.
3- Use this access_token to retrieve your talents list:
GET https://management.azure.com/tenants?api-version=2016-06-01
Authorization: Bearer access_token
And you can test this via postman or any curl based tool for verifying.
I am stuck with the authentication to use the REST API for getting subscription billing information from Resource Usage API
I would like to get help with how to obtain token for non interactive clients. I chose to use the REST API since azure client seems to not support Resource Usage API.
As the Authorization code grant (interactive clients) describes , I have called the request with my subscription id but token is not returned properly.
[root#visual src]# curl -XPOST https://login.microsoftonline.com/xxxxx/oauth2/token -d ""
{"error":"invalid_request","error_description":"AADSTS90014: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: 32981285-a021-45c3-8d2f-62db49d2c2f1\r\nCorrelation ID: d88849dd-20f9-462e-9ce9-66b6fde0170e\r\nTimestamp: 2017-03-04 04:06:44Z","error_codes":[90014],"timestamp":"2017-03-04 04:06:44Z","trace_id":"32981285-a021-45c3-8d2f-62db49d2c2f1","correlation_id":"d88849dd-20f9-462e-9ce9-66b6fde0170e"}[root#visual src]#
How can I obtain the token?
A token will not be returned if you don't supply some credentials :)
If you want to do a non-interactive request with client credentials for example, your request must contain (in URL-encoded form format):
grant_type=client_credentials
client_id=your-app-client-id
client_secret=your-app-client-secret
resource=resource-uri-for-api-you-want-the-token-for
The resource URI could be for example https://graph.windows.net/ for the Azure AD Graph API.
You can also get tokens with the password grant if you wish to use a username and password. In that case, you must send:
client_id, client_secret and resource as above
grant_type=password
username=your-username
password=your-password