You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Only the sub and sub_legacy claims are included in the ID token, all other claims are available from the /oauth/userinfo endpoint used by OIDC clients.
I first attempted to integrate with GitLab using the generic oidc provider like so:
{
identity: {
traits: {
[if "email" in claims && claims.email_verified then "email" else null]: claims.email,
},
},
}
Without making the additional call to gitlab.com/oauth/userinfo, claims doesn't contain the email and therefore no row is added to the identities table.
I'll open a draft pull request shortly with what I was able to get working. But I'm wondering if I'm missing an existing feature of kratos that would support this. The only alternative I can think of would be to use an http mapper_url and make the call in that route before responding.
If this could be a common use-case, should an additional field be added to the provider schema. Something like user_info_url which would contain the url used to fetch the full claims?
According to GitLab's documentation
I first attempted to integrate with GitLab using the generic oidc provider like so:
with oidc.gitlab.jsonnet containing
Without making the additional call to gitlab.com/oauth/userinfo, claims doesn't contain the email and therefore no row is added to the
identities
table.I'll open a draft pull request shortly with what I was able to get working. But I'm wondering if I'm missing an existing feature of kratos that would support this. The only alternative I can think of would be to use an http mapper_url and make the call in that route before responding.
If this could be a common use-case, should an additional field be added to the provider schema. Something like
user_info_url
which would contain the url used to fetch the full claims?Related Open Issues in GitLab:
The text was updated successfully, but these errors were encountered: