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

Support GitLab as OIDC Provider #518

Closed
perryao opened this issue Jun 17, 2020 · 0 comments · Fixed by #519
Closed

Support GitLab as OIDC Provider #518

perryao opened this issue Jun 17, 2020 · 0 comments · Fixed by #519
Labels
feat New feature or request.
Milestone

Comments

@perryao
Copy link
Contributor

perryao commented Jun 17, 2020

According to GitLab's documentation

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:

selfservice:
  strategies:
    oidc:
      enabled: true
      config:
        providers:
          - id: gitlab
            provider: generic
            client_id: "ID"
            client_secret: "SECRET"
            issuer_url: "https://gitlab.com"
            auth_url: "https://gitlab.com/oauth/authorize"
            token_url: "https://gitlab.com/oauth/token"
            mapper_url: file:///etc/config/kratos/oidc.gitlab.jsonnet
            scope:
              - read_user
              - openid
              - profile
              - email

with oidc.gitlab.jsonnet containing

{
  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?

Related Open Issues in GitLab:

@perryao perryao mentioned this issue Jun 17, 2020
5 tasks
@aeneasr aeneasr added this to the unplanned milestone Jul 8, 2020
@aeneasr aeneasr added the feat New feature or request. label Jul 8, 2020
aeneasr added a commit that referenced this issue Oct 13, 2020
Closes #518

Co-authored-by: hackerman <3372410+aeneasr@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants