Userinfo when using a generic provider

[robinknaapen]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

Kratos does not utilize userinfo call even though a provider has to be OIDC compliant.

In my scenario I have a legacy oauth2 server that is used by some applications. I did not want to alter existing code of this server.
So I choose to create a layer above this server that implemented the OIDC layer as well as the userinfo call.

This userinfo call returns some extra information that is necessary for newer applications and this information is not pressent in the id_token.

I've scoped through the code of the generic_provider and I could not see a userinfo call being used.

I can confirm this when I am going over the login flow and follow traces in the new service. No calls are made to the new userinfo call.

Reproducing the bug

• Deploy a Kratos instance
• Deploy a OIDC compliant service that returns a trait over the userinfo call that is not pressent in the id_token
• Configure this service using the generic_provider in Kratos
• Follow the login flow and login via OIDC with the above-mentioned service

The trait will not be in the received claims in the jsonnet mapper.

Relevant log output

No response

Relevant configuration

For debugging purposes, I have outputted all the claims to the traits object in the jsonnet mapper.


# kratos.yml
selfservice:
    oidc:
      enabled: true
      config:
        providers:
          - id: oidc_provider
            provider: generic
            subject_source: userinfo
            issuer_url: http://localhost:8081
            mapper_url: file://./mappers/oidc_provider_mapper.jsonnet
            requested_claims:
              id_token:
                ? name
              userinfo:
                ? custom
            scope:
              - profile 
              - openid

# ./mappers/oidc_provider_mapper.jsonnet
local claims = std.extVar('claims');

{
  identity: {
    traits: {
      claims: claims
    },
    metadata_public: {},
  },
}

### Version

v1.0.0

### On which operating system are you observing this issue?

Linux

### In which environment are you deploying?

Docker Compose

### Additional Context

_No response_

[robinknaapen]

Related issues:

#3182
#518

---

I have found other issues mentioned above; but the solution was to create a custom provider. I understand in this case, since the implementation is pretty specific. But was a generic_oidc_provider considered anywhere along the way?

[robinknaapen]

Fixed by: #3718