Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The OpenID Connect authenticator does not use the userinfo endpoint by default #9316

Open
matrixbot opened this issue Dec 18, 2023 · 1 comment

Comments

@matrixbot
Copy link
Collaborator

matrixbot commented Dec 18, 2023

This issue has been migrated from #9316.


I don't get any of the user information (I would have expected to see at least the display name and the email) available through the userinfo endpoint (available in the discovery endpoint) synchronized with my matrix account.

According to https://github.com/matrix-org/synapse/blob/v1.26.0/synapse/handlers/oidc_handler.py#L342 the authenticator seems to assume that the concept of userinfo endpoint is not really part of the OpenID Connect protocol and expect user related claims to be provided by the id token as soon as the scopes contains "oidc".

From what I can see in the OIDC specification the only user related information the id token is supposed to contain is the subject and if the authenticator need to resolve all the user claims (those par of profile and email) it asked the authentication endpoint to authorize it's supposed to go through the userinfo endpoint.

Synapse version: 1.26.0

My oidc config:

oidc_providers:
  - idp_id: adm
    idp_name: "My Provider"
    issuer: "https://myhost/oidc/"
    client_id: "matrix"
    client_secret: "dontcare"
    scopes: ["openid", "profile", "email"]

I'm testing with https://app.element.io as client.

@matrixbot matrixbot changed the title Dummy issue The OpenID Connect authenticator does not use the userinfo endpoint by default Dec 21, 2023
@matrixbot matrixbot reopened this Dec 21, 2023
@tobast
Copy link

tobast commented Jun 21, 2024

Hello, I found myself confronted with this same issue today.

I use LemonLdap::NG as a SSO provider which, by default, fills the id_token only with core user attributes. The OIDC reference states, in its section about id tokens, that the token MAY (in the RFC sense) contain other claims; that is, it may just as well not include other claims without breaking the normative text. However, the comment here suggests that the authors assumed that the token MUST contain other claims.

As such, the userinfo endpoint should be queried to fill the user infos: by default, my SSO provider did not provide preferred_username, resulting in a 500 error because the correctly-identified used had an empty localpart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants