OpenID: Internal Server Error #864
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#864
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'm configuring a self-hosted instance of GitLab to serve as the OpenID IdP for my Vikunja instance.
I'm seeing that when the frontend calls
/callback
however, the API returns a 500 withmessage: "Internal Server Error"
I've enabled all debug logging, and the only error message I see is:
Which isn't very helpful... 😅
I'm assuming this is related to this section of the code, but I don't see any obvious bugs.
My
config.yml
:I can confirm this with gitlab.com. I'll take a look.
Okay so it looks like gitlab does not send the email of the user with the oauth response.
The user authenticating with gitlab has to set their public email address to something, otherwise it is not exposed to the openid connect port. See https://forum.gitlab.com/t/openid-connect-user-info-missing-email-claim/21902/2
I'll update the docs and error messages to clarify this.
Added more docs and better errors in
b76ad8efe2
I'd consider this issue solved, please don't hesitate to reopen if you have any issues.
Still doesn't seem to be working, unfortunately, but I think I know the cause now.
The initial request to
/authorize
specifiesscope=openid
, but based on the OIDC spec that won't return the user's email. For that you would needscope=openid email
. And most apps I've seen also want to store the user's first name, last name, and preferred username, which you can get withscope=openid email profile
, so perhaps let's try that?I also just want to confirm you're aware per the spec that
email
andpreferred_username
claims are not guaranteed to be unique or consistent over time, as users can potentially change both in the OpenID provider. So you shouldn't use them to look up a user during authentication, you should use theiss
uer and thesub
ject claims together.Oh I supppose I should mention, I did retry with GitLab, but it also took me a few days to respond because I set up a completely different identity provider (Authentik) to do a second test. That one didn't work either, which leads me to believe it is a problem with the
scope
parameter.This was the config I've tried:
Can you reproduce it with gitlab.com?
Remember, the gitlab user you're authenticating with needs to have one email address which is publicly visible.
Yes, I'm doing that. But I need an email address to associate with the newly created account. Subsequent authentications with the same (sub, iss) tuple will check if the email address changed and update if nessecary.
The scopes used during the authentication are actually
openid
,email
andprofile
: https://kolaente.dev/vikunja/api/src/branch/main/pkg/modules/auth/openid/providers.go#L140Perfect. My apologies if I came off rude at all, I just know first-hand how tricky OIDC can be to implement. 🙂
I tested just now with GitLab.com, verified my email was public first, same
Internal Server Error
....Which is odd considering I pulled the latest container images. I would have expected to see the new error messages you added, but I'm still seeing the
Unmarshal
error. Is thelatest
tag on Docker Hub supposed to be a build ofmaster
or am I mistaken?This also doesn't explain why Authentik isn't working either. That one I think is a result of not passing
email
inscope
, but since I also just got it set up I'll do a little more testing with a different app to confirm.No worries 🙃
Since you're on latest, could you turn on debug logging and send the output? Latest always represents the build from the
main
branch.Authentik looks interesting, I'll try to reproduce with that.
I was able to reproduce this with an Authentik instance, but not sure why it does not work - AFAIU Authentik sends all claims in the
id_token
as per their settings.I'll take a look.
Authentik does not seem to send the email, even when requested through the
/userinfo
endpoint. That's interesting.I've asked the Authentik guys on their discord server about this and they don't really have an idea about it either - we're currently figuring out a way to properly debug this.
@konrad I'm seeing the
/authorize
URL coming out of both Authentik and GitLab.com looks like this:Note that the
scope
only containsopenid
, despite the fact that you've set it inproviders.go
. 🤷♂️Can you open your browser Network inspector and confirm
email
is there on your request to GitLab.com? If not, that rules this out, but if it is I still suspect that's the cause.I also noticed that and added the scopes in
188c97ae8f
- it did not fix the issue with Authentik though. With gitlab it works either way, with Authentik it doesn't work in either case. Gitlab seems to ignore what scope you sent it and just uses whatever you set when creating the application.I'm pulling
latest
of both theapi
andfrontend
containers. Still seeingscope=openid
, andopenid/HandleCallback ... json: Unmarshal(nil)
errors in the logs.No sign of either change you've made, what might I be doing wrong? 🤔
Only the CRON seems to be outputting anything
DEBUG
, doesn't look relevant.Does it work with a cleared browser cache or in a private window?
The frontend should be version
0.17.0+4-fd610d3721
.What version is your api container? (
docker run vikunja/api /app/vikunja/vikunja version
)With the help of the people at the Authentik Discord server, we've figured out a workaround: If you unselect the scopes of the provider, save it, then reselect the openid, email and profile scopes and save it again it works. I was able to reproduce it with that.
(You'll need the latest version of the frontend though)
Ok, I've given up on getting Authentik working, the whole getting started experience felt half-baked and not well documented. Back to getting Gitlab working.
I have:
vikunja/api:latest
andvikunja/frontend:latest
images as of the time of this comment and verified theapi
container isv0.17.0+11-67f863120e
(not sure how to check frontend version?)openid
,email
, andprofile
scopes checked, and a redirect URI ofhttps://vikunja.example.com/auth/openid/gitlab
Still doesn't work. For the first time I do see
scope=openid email profile
in the request, but stillUnmarshal
in the Docker service logs, not the better error messages you added.Why am I not seeing those better error messages? Am I still pulling the wrong version of the container?
The API version seems correct, but the error is really weired. Can you reproduce that with gitlab.com?
Found it.
Once you said this, I figured it couldn't be related to the OpenID code anymore. So I did a search for
Unmarshal
, and I'm pretty certain it's this line that's throwing the unhelpful message now.If I change my
keyvalue
type fromredis
tomemory
, it works. Howevercache
type set toredis
works just fine. 🤔 Mind adding a better log message to that spot so I can figure out why?Also - I notice the UI sets my full name to my preferred username when I first log in, then sets it to my actual full name on second log in. Doesn't seem like expected behavior, is it? Happy to file another bug if so.
That could be the error yeah. I'll take a look. But using memory should work fine, most of the time you'll only ever need redis if you have a lot of concurrent users.
Is that with gitlab? I've added some functionality to check if the openid provider provides these fields on the initial request and then does a call to the
/userinfo
endpoint if they are not there. Maybe gitlab sends different data for these different requests. Needs more debugging I'd say.But yeah, that'd be a differnt issue.
Yeah, that was with GitLab. I filed a separate issue for it, as you can see. 🙂
I'm not blocked on this issue anymore, but still happy to help debug this further if you'd like assistance. In particular that
Unmarshal
error message - let me know if you add some more logging around it and I'll test it out again.I've done some changes to how values are stored in redis in
d48aa101cf
. Would you mind checking if that fixed theUnmarshal
error when using redis?Apologies for the delay 🙏
I cannot reproduce the
Unmarshal
error anymore, so I think it's resolved! Thanks very much for your efforts, marking this one closed.