We’re encountering an issue with Azure B2C authentication and hoping someone here might be able to help. Despite having all configurations seemingly correct, we are getting a failure when sending the authentication code.
Here are the details of the error we're encountering:
{
"message": "Failed to identify user for token: 942d15d931cd2961b39fca895e5cf669 deploymentId: 91bad5ae-7619-4ee9-918e-7c9c1cbdbc81",
"code": "unauthorized",
"status": 401,
"contextId": "5e6acc3a-004f-497c-ae81-8020513454ab",
"details": [],
"errors": []
}
We have double-checked the configurations and they appear to be correct. However, we are still receiving a 401 Unauthorized error.
Has anyone experienced a similar issue or have any suggestions on how to troubleshoot this? Any help or insights would be greatly appreciated!
I'm seeing the following error message: invalid_grant (AADB2C90087: The provided grant has not been issued for this version of the protocol endpoint. Correlation ID: b77ef0ee-1102-4ea2-91fd-cbddafb90c57.
I'm not sure about that. In the authentication flow, we are using the /oauth2/v2.0/authorize and /oauth2/v2.0/token endpoints. However, I am checking the /.well-known/openid-configuration endpoint and the URLs don't contain the /v2.0/.
Yes, could be indeed. How did you get the endpoints ?
As far as I know, endpoints are given by Microsoft portal.
You can check them for your application.
It's a bit weird because we use the authorize flow inside a WebView and then we use the code to get the common token request without using client_secret. And the first code after login works when I use it in a normal web flow but fails on app the app flow.
This is likely the issue. Genesys OpenID integration always sets the secret when exchanging the code (ie. when invoking the /token endpoint).
Currently, public clients are not supported. You have to use a client secret.
So one possible solution would be to create a website with private authentication flow and use it as a bridge between the mobile app, B2C, and Genesys.
That could be an option.
Keep in mind that troubleshooting authentication with "more layers" could be a challenge.
Feel free also to open a feature request if you think that supporting public client (ie. authentication without secret) is required for your use case.
Nobody asked for that so far.