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 trying to retrieve the web job history of an Azure web job via REST using a .NET backend and the OAuth2 credentials flow (as described here
https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/get-triggered-web-job-history-slot)
How do I need to authenticate correctly?
I retrieve the token as follows:
POST https://login.microsoftonline.com/{MySubscription}/oauth2/v2.0/token
client_id={MyApp}
&grant_type=client_credentials
&scope=https://management.azure.com/.default
&client_secret={myclient_secret}
I get a token back, however I get a 403 error message when I try to retrieve the resource:
GET https://management.azure.com/subscriptions/{MySubscription}/resourceGroups/{MyResource}/providers/Microsoft.Web/sites/{MyApp}/slots/{MySlot}/triggeredwebjobs/{MyWebjob}/history?api-version=2021-02-01
Authorization: Bearer {MyToken}
Client '{MyApp}' with object ID '{MyApp}' is not
authorized to perform the action
'Microsoft.Web/sites/slots/triggeredwebjobs/history/read' using the
scope
'/subscriptions/{MySubscription}/resourceGroups/{MyResource}/providers/Microsoft.Web/sites/{MyApp}/slots/{MySlot}/triggeredwebjobs/{MyWebjob}'
or the scope is invalid. If access was granted recently, please update
your credentials.
What am I doing wrong?
I already added the API-Permission
The "403 Token invalid" error usually occurs if you missed giving permissions to particular scope (Azure Service Management).
By giving this scope it enables you to access https://management.azure.com
To resolve this error, please follow below steps:
Go to Azure Ad ->your application -> API permissions -> Add permission -> Azure Service Management -> delegated permissions ->User impersonation -> Add
After giving these permissions try to retrieve the resource again, there won't be any error.
Since I didn't find a solution that worked with OAuth2 and the Credentials flow, I got it working with Basic Authentication. The username (userName) and password (userPWD) can be taken from the publishing profile of the respective app service.
GET https://{appservicename}.scm.azurewebsites.net/api/triggeredwebjobs/{jobName}/history
Authorization Basic ....
I'm trying to authenticate to my B2C AD tenant on Azure AD B2C. I'm using OAuth 2.0 on aspnet .NET 6
If I request a new bearer token using Client Id
0fdd4f3b-xxxx-xxxx-xxxx-3f84bd9d02ax
I get back an aud value
https://mysite.onmicrosoft.com/0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax
I'm using
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));
If I use 0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax in my config, he tries to validate it by prefixing Client ID with api:// and the following exception:
IDX10214: Audience validation failed. Audiences: 'https://mysite.onmicrosoft.com/0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax'. Did not match: validationParameters.ValidAudience: 'api://0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax'
If I use https://mysite.onmicrosoft.com/0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax in my config, he tries to validate it by prefixing Client ID with api:// and the following exception:
IDX10214: Audience validation failed. Audiences: 'https://mysite.onmicrosoft.com/0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax'. Did not match: validationParameters.ValidAudience: 'api://https://mysite.onmicrosoft.com/0fdd4f3b-xxxx-xxxx-a438-3f84bd9d02ax'
Why is the value always prefixed with api:// ?
Ok, apparently Stack Overflow was my rubber ducky.
If your Application ID URI does not start with api:// you'll have to make a manual change to the manifest of your application and switch to access tokens version 2.
Then change the value of accessTokenAcceptedVersion from null to 2
Now you can go back to your local application configuration and set the value of ClientId to the GUID only not including https://xxx.onmicrosoft.com/.
I have Java application which provides some reports in plain HTML.
I want to secure these reports with Microsoft SSO (OAuth).
I was able to do this in browser - I created new "AppRegistration" in Azure AD, get client_id, client_secret, Oauth 2 authentication_url, configured correct redirect_uri in this application and implemented Oauth flow in browser - it works as expected.
But users don't want to check reports in browser, they want to process them in Excel 2019.
It has "Organizational account" authentication.
I believe, that it uses the same OAuth 2 flow.
So, I added WWW-Authenticate: Bearer authorization_url="https://login.microsoftonline.com/256be541-f611-4412-975e-cb56ee6fb03b/oauth2/v2.0/authorize"
I'm trying to access URL like: https://localhost:8443/report/1
Now Excel asks me to enter login and password, but after successfull authentication the error is shown:
invalid_resource: AADSTS500011: The resource principal named https://localhost:8443 was not found in the tenant named 256be541-f611-4412-975e-cb56ee6fb03b. 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.
Trace ID: 57324bfe-ab46-4c2e-9128-a336aa287e00
Correlation ID: d9c4c732-76cc-4659-9d8a-d27abec617d3
Timestamp: 2021-02-02 16:50:13Z.
https://localhost:8443 - is address of my application and this address is included to redirect_uri in App registration.
But I don't think that mentioned "resource principal" is about redirect_uri.
So, how can I create "resource" principal in Azure AD and give it name "https://localhost:8443" ?
In fact, this is the case. According to your error message, it says that the resource body of https://localhost:8443 cannot be found, which means that you set the scope to: https://localhost:8443 when requesting an access token.
However, you only set it to redirect_uri at the beginning, and did not set the Application ID URI to: https://localhost:8443 in the Expose API tab, so when you request the resource, the error message will report that it cannot be found the resource.
By the way, scope is different from redirect_uri. The scope puts the resource you want to access, while redirect_uri is just the callback url that is not the resource you want to access. This is why you still get an error when setting the url in redirect_uri.
I configured azure AD as an identity provider for my organization's application
whenever i try to access the application its redirecting the request to azure login. But I am getting a bad request error and its showing the below message
The SP name qualifier 'abc.xxxx.com' is not valid.
I am not sure if i have done something wrong.
Below is my configuration
SIGN ON URL
https://abc.xxxx.com/myapp/saml/ssoRequest?ticket=kcflmlmnpgg
ISSUER URL
https://abc.xxxx.com
REPLY URL
https://abc.xxxx.com/myapp/ssoResponse
The problem was when i was submitting the SAML request I was not prepending the 'http://' in the service provider name