OIDC with Gitlab
Even with https://github.com/coder/coder/pull/5507 merged have no success with gitlab as OIDC provider. If I put a debug print of the claims data here: https://github.com/coder/coder/blob/main/coderd/userauth.go#L253 I something like this:
The nickname is completely missing. Has anyone an idea what I do wrong?
GitHub
feat: allow configurable username claim field in OIDC by janLo · Pu...
Gitlab does not set the preferred_username field.
Therefore, coder generates something from the user's email address, which is not very helpful. This allows the administrator to change the fiel...
GitHub
coder/userauth.go at main · coder/coder
A tool that provisions remote development environments via Terraform - coder/userauth.go at main · coder/coder
32 Replies
By default all custom claims are only returned from the UserInfo endpoint and not included in the ID token. You can optionally pass a response: keyword with one or both of the symbols :id_token or :user_info to specify where the claim should be returned.
GitHub
GitHub - doorkeeper-gem/doorkeeper-openid_connect: OpenID Connect e...
OpenID Connect extension for Doorkeeper. Contribute to doorkeeper-gem/doorkeeper-openid_connect development by creating an account on GitHub.
could this be teh reason? Can I somehow "fix" this?
(on the coder side)
Hmm, interesting. I'm not exactly sure how we'd go about fixing it.
To be certain I'm following, you need the "nickname" claim to appear for a username, but it seems to only pass that if special parameters are passed to the request?
No, you need to request this from the user info endpoint after fetching the id token.
https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc#Provider.UserInfo
I can try to implement it myself but might need some help with the unittests (client mocking) as I'm not a regular go developer.
I'll in parallel open an issue at gitlab to provide basic information within the id token maybe. Not sure it was a deliberate decision on their side to only make this available within the user info ep
I see! Is
id_token
returned?Yes
The id token is apparently the only MUST part in the standard
Ahh, gotcha. So if there are no claims, then we should be executing the
Provider.UserInfo
call?exactly
This does the trick.
The only thing is - now the unittests need to be fixed and I have no capacity in at the moment to understand the http client mocking
Neato. I'll put up a fix right away and we can do a release for you!
Shall I create a PR anyway?
Thanks for investigating 🙂
Nah, I'll just steal your patch. I'll mention your GH username @JanLo
thank you!
I'm going to do this in a bit of a different way. My code is going to assume that the
id_token
has zero claims attached - is that a fair assumption?I cannot really tell if that is always true, the OIDC standard says, it can be in either or. For gitlab this is true - but this is only one provider
But in this specific case is it true?
This specification defines a set of standard Claims. They can be requested to be returned either in the UserInfo Response, per Section 5.3.2, or in the ID Token, per Section 2.ah, you mean, fetch user info if no claims are attached?
Yup!
Current code:
Not sure if it returns no claims though. If it returns some claims, then we have a wonky situation ;p
that is not true, gitlab strange enough sends teh direct group memberships and the user email in the id_token claim
Hmm, very unfortunate
yes. I'm not sure if they created this situation deliberately or if it happened just because someone did not fully read the documentation of the library they used 😉
I'll definitely open an issue on the GL side
For this case, I think it's acceptable to do this extra work on the coder side becuase this code is only hit if someone provided a valid oidc callback anyway - so I don't see much potential for dos
GitLab
Provide OIDC nickname/preferred_username claims in id_token (#38817...
The OIDC feature provides a lot of information as documented in https://docs.gitlab.com/ee/integration/openid_connect_provider.html#shared-information. I tried to use this with an external application...
@JanL PR almost up!
GitHub
fix: use
UserInfo
endpoint with OIDC by kylecarbs · Pull Request ...This resolves a user issue surfaced in Discord:
https://discord.com/channels/747933592273027093/1064566338875576361/1064566338875576361
Both methods of obtaining claims need to be used according to...
Oh wow, thank you so much!
@JanL can you build from
main
to try it out?
Or do you need us to cut a release?I'll test it first thing tomorrow morning, I've turned my device off already. Is it alright to cherry-pick just this commit on top of the last release? Then I don't need a separate release for just this change.
Yup, you should be able to cherry it!
Let me know if there are any issues!
👍
Sorry for the late feedback, I got distracted this morning. The patch works perfect. Thank you!
Awesome!