UserInfo not found

[tobru]

Following #263, the next issue I now see in the Forgejo log is:

2024/02/09 15:50:33 ...rs/web/auth/oauth.go:937:SignInOAuthCallback() [E] UserSignIn: Non-200 response from UserInfo: 404, WWW-Authenticate=

The configuration looks like this:

I checked the content of https://id.example.com/auth/v1/.well-known/openid-configuration: The field userinfo_endpoint points to https://id.example.com/auth/v1/oidc/userinfo. Manually curl-ing this endpoint gives:

{"timestamp":1707494056,"error":"BadRequest","message":"Authorization header missing"}

This is expected, as I'm not authenticated with curl.

Any idea what's wrong?

[sebadob]

This is expected, as I'm not authenticated with curl.

Correct, the userinfo endpoint expects a valid access token as Bearer in the Authorization header.
You could add this header with the -H option with curl for testing.

Regarding the 404, this is probably coming from the newly added additional user values with this beta version. If there is not a single custom value added for the user, the table in the DB actually has no entry yet. If this is the reasons, then this is a bug in the beta version, which would make sense to me now without having too much time to dig depper into this.

You could actually help me out here. If I am correct, this error should be gone as soon as you add any custom value to your user in your account page apart from the mandatory first name, last name and email. For instance, if you would add lets say a ZIP or something like that and try again, will this solve the 404 error? If so, I can provide a fix tomorrow, as this would be pretty easy.

[sebadob]

Sorry, my bad, I found the issue.

This is actually a bug. The custom user values is not the issue, these will just be empty if no entries do exist.
The issue actually came up from the sub claim fix. The endpoint expects the email to be the sub instead of the user id. If just needs to fetch the user by ID, not by email.

I will provide a fix for this latest until tomorrow.
And probably an integration test for this endpoint would make sense now. :D

[tobru]

Thanks for your investigation. For me, there is no hurry for a fix, I'm happy to help to make rauthy work for "standard" apps.

[sebadob]

Thanks for your investigation. For me, there is no hurry for a fix, I'm happy to help to make rauthy work for "standard" apps.

Thanks a lot. That's always really helpful, when others test with real world apps as well.
For instance, #263 was the first app, that (correctly) complained about the difference in the sub claim.

[tobru]

I deployed v0.21.0-beta2 and this error is gone. But, the one from #263 is back:

2024/02/10 10:08:13 ...rs/web/auth/oauth.go:937:SignInOAuthCallback() [E] UserSignIn: userinfo 'sub' claim (my@example.com) did not match id_token 'sub' claim (MyUiDFromRauThy)

[sebadob]

I deployed v0.21.0-beta2 and this error is gone. But, the one from #263 is back:

Yes I know, because I forgot to include the fix for the response mapping, even though I adopted the code. Sorry.

Edit:

I needed to move to another machine because I was not able to build the code. It seems that the current ld on Fedora has some internal issues. It threw a non reproducible bug from time to time when linking code. It was just one line that got lost, which now means to wait ~45 minutes for one line of code. :D
-beta3 is building right now.

[sebadob]

The beta3 should be good now, can you test again?

[tobru]

Good news! beta3 works! I could successfully log in to Forgejo using rauthy. This will end up in a blog post 👍

[sebadob]

Thanks a lot for testing!

I plan to release v0.21.0 on monday.