Unnecessarily picky on openid issuer #1195

Closed
opened 2022-06-29 22:39:12 +00:00 by xeruf · 3 comments

Maybe that's intended, but this does not seem like a sensible distinction to me:

Error while getting openid providers for /info: oidc: issuer did not match the issuer returned by provider, expected "https://sso.DOMAIN" got "https://sso.DOMAIN/"

Maybe that's intended, but this does not seem like a sensible distinction to me: > Error while getting openid providers for /info: oidc: issuer did not match the issuer returned by provider, expected "https://sso.DOMAIN" got "https://sso.DOMAIN/"
Owner

The problem is that this configuration depends on what the provider returns so we can't just always add a / at the end.

The problem is that this configuration depends on what the provider returns so we can't just always add a `/` at the end.
Author

can't it simply accept both?

can't it simply accept both?
Owner

Your provider might accept both, but as far as I understand it this is some sort of security measure to make sure the endpoint hasn't been tampered with. Basically Vikunja does a lookup to the provider's .well-known openid endpoint to get all urls it needs to actually do the openid login. Included in that url there's the issuer url which Vikunja partly used to get the openid info from the provider in the first place. It then compares the two and errors out if they don't match.

I've looked briefly into changing it but there's no easy way to convince the library we're using to accept both. It's a lot easier to just change the configured value in Vikunja to match what the provider returns.

Your provider might accept both, but as far as I understand it this is some sort of security measure to make sure the endpoint hasn't been tampered with. Basically Vikunja does a lookup to the provider's `.well-known` openid endpoint to get all urls it needs to actually do the openid login. Included in that url there's the issuer url which Vikunja partly used to get the openid info from the provider in the first place. It then compares the two and errors out if they don't match. I've looked briefly into changing it but there's no easy way to convince the library we're using to accept both. It's a lot easier to just change the configured value in Vikunja to match what the provider returns.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1195
No description provided.