I’m trying to add GitLab as an OIDC provider.
After filling in and submitting the “New Open ID Connect Connection” form using https://gitlab.com/.well-known/openid-configuration as the Issuer URL I receive this error:
Error! Something happened while trying to create your connection: Issuer metadata missing the following attributes: token_endpoint
There’s definitely a token_endpoint property in the JSON at the configuration URL, so I’m not sure what’s causing the error.
Having the same issue. Token_endpoint is in the json at the configuration url.
Hi everyone.
Thanks for reporting this. I’ve taken this to the engineering team and they are already working on it, so this should be fixed very soon.
We’ve reverted back to the old UI in the meantime so that you should be able to create them immediately (after refreshing the Dashboard page).
Having the same issue on https://oidc-current.bankidapis.no/auth/realms/current/.well-known/openid-configuration
We plan to use Auth0 service for enterprise clients and this feature one from the most important for them. I need at least approximately time how long it will take to fixing this problem.
Hi @mlukianenko. This seems to be a different problem. Thanks for reporting it, I’m notifying the engineering team right now. Will keep you updated.
Hi again @mlukianenko. Can you give it a try now?
Hi @nicolas_sabena, the same " Error! Something happened while trying to save your connection: Issuer metadata missing the following attributes: token_endpoint"
did you try refreshing the page?
I tried the issuer URL you provided on my side after the fix and was able to create a new connection.
Oh, ok, I see the problem.
The system is defaulting to front_channel, which is a more optimal way of doing OIDC if the OIDC Provider supports it, and when auto-selecting front_channel the token endpoint is forgotten.
Is the front_channel flow not working for you?
When I am trying to use “Front Channel” I get the error when I’m testing the connection:
{
"error": "access_denied",
"error_description": "unsupported_response_type (Client is not allowed to initiate browser login with given response_type. Implicit flow is disabled for the client.)"
}
But i I need response_type=code.
I understand.
It seems that the metadata in this case is reporting that an “id_token” response is available even though the client is missing a specific configuration to actually support it (implicit flow, according to the error message, although we are technically asking for a hybrid flow).
In any case, you should be able to force back_channel for whatever reason. I’ve reported this to the team again, will let you know when there’s an update.
This is still a problem for us. And in regards to your comment about “token endpoint being forgotten when auto-selecting front_channel”, I cannot find a field to explicitly set this? Are you referring to a hidden field being cleared or something (like a system bug), or is this something we’re able to fix ourselves?
By the way. The config-endpoint used in this picture is https://demo.identityserver.io/.well-known/openid-configuration, which contains token_endpoint
EDIT: By some reason I missed the last paragraph of your last post. Guess you can ignore this post then. My bad
Hi @nicolas_sabena. Thanks for your help. I requested additional information in BankID and their response:
Implicit flow and Hybrid flow was previously supported by the OIDC Provider from BankID. This support has been removed due to a recent security best practice recommendation from IETF.
If you change response_type from id_token to code in the example it should work, but it requires a backend integration to retrieve the token.
@mlukianenko the OAuth2 working group recent best practices talk about the implicit flow (see OAuth2 Implicit Grant and SPA) mainly because it includes the access token on the URL.
We default to the hybrid flow (which is a perfectly OK flow) if the discovery document indicates that the OIDC provider can handle response_mode=form_post and response_type=id_token. This sends the ID token in a form post instead of through the URL. The advantage of this flow is:
In any case, as I said before, even though we default to the front channel, you should be able to change it.
We just deployed a quick fix where, after saving the connection, you should be able to change the type to “back_channel” and get a field to type the token endpoint (click on Show Issuer Details to see the field).
For now you’ll need to read it from the discovery URL, but next week we’ll get it directly from the discovery URL even if we default to front channel, so that you can switch to back channel seamlessly without having to type the token endpoint.
Let me know if that works for you.
Hi @nicolas_sabena, yes it works. Thank for your help.
Glad to hear that you have it working now @mlukianenko, thanks to @nicolas_sabena knowledge! Perfect!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
