Support for parsing userID, username, etc out of nested JSON objects

[jwtrhs]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

I have been trying to use SourceHut as an OAuth2 connector in Dex. My problem is that SourceHut's API uses GraphQL which returns user information in a nested JSON object.

What I've got so far, I'm trying to use the following connector:

- type: oauth
  id: sourcehut
  name: SourceHut
  config:
    clientID: $SOURCEHUT_CLIENT_ID
    clientSecret: $SOURCEHUT_CLIENT_SECRET
    redirectURI: https://dex.example.com/callback
    tokenURL: https://meta.sr.ht/oauth2/access-token
    authorizationURL: https://meta.sr.ht/oauth2/authorize
    userInfoURL: https://meta.sr.ht/query?query={me{id%20username%20email%20canonicalName}}
    scopes:
      - meta.sr.ht/PROFILE:RO
    userIDKey: data.me.id

The userInfoURL is a GraphQL endpoint that returns something like:

{
  "data": {
    "me": {
      "id": 1,
      "username": "jwtrhs",
      "email": "[email protected]",
      "canonicalName": "~jwtrhs"
    }
  }
}

I can see in the code that the userIDKey is expecting only a top-level key, not nested. So of course my attempt at using data.me.id fails.

Proposed Solution

Some way to specify a userIDKey and other claims that can parse data out of a nested JSON structure. The "dot" notation I've tried would conflict with keys that actually have dots in them. Maybe a nested YAML definition?

userIDKey:
  data:
    me: id

Alternatives Considered

No response

Additional Information

No response

[nabokihms]

@jwtrhs I believe there was a discussion or PR about it, but I couldn't find it.

Because OIDC tokens are highly customizable, there can be not only nested fields but also cases like

1. Groups claim are represented by a string delimited by commas, not an array.
2. Username claim is a combination of two claims of the OIDC token, e.g., first_name and surname.

To solve this problem, I think it would be best to introduce query language support. It will also help us to solve the middleware issue #1635

https://github.com/google/cel-go is an example of a robust embedded expression language

[nabokihms]

related #2563