Google has different refresh token limits for OAuth2 and OIDC. The current limit for OIDC protocol is one per client/user combination (https://developers.google.com/identity/protocols/OpenIDConnect)

@rithujohn191

Thanks for the information. I understood that Google is limiting the number of OIDC refresh tokens to 1 just like dex.

But my request is just to make the limit of refresh token configurable. This is in order to implement an application that support multiple offline sessions, for example from mobile and laptop clients. That behavior doesn't seem to violate OAuth2 and OIDC specifications.

Sorry for misunderstanding. Yes this would require some infrastructure re-work and is currently not on our road map but hope to support it someday.

Any news about including the feature into the roadmap? We very need it.

As much as I'd like to carry on using Dex, this is causing me problems using Dex with my Kubernetes cluster for dashboard and CLI authentication. I'm still understanding exactly what's going on, but it seems that if the one uses the refresh token, the other can't - e.g. if my dashboard proxy uses the refresh token, when the CLI tries to refresh later it can't.

It's worth pointing out that the Google docs linked to above do not actually say what the limits are, just the there is one limit per client/user combination and another limit per user across all clients.

Different clients should definitely be using different credentials. Your CLI should be using different client_id and client_secret than the dashboard.

Tectonic got around this by using our audience scope, you might want to check that out https://github.com/dexidp/dex/blob/master/Documentation/custom-scopes-claims-clients.md#scopes

Regarding 1418 had a concern,

Thanks, could you tell the maximum number of oidc client entries that can be used for a single dex instance. I am centralizing/separating dex authentication and need it to support <30 clusters. The OIDC client is Gangway but for uniqueness, the client ID and secret are different for every entry in dex config.

staticClients:
- id: K8s-Authentication
  redirectURIs:
  - 'https://login-app.ex1.com/ui'        
  name: 'Dev Cluster1’
  secret: ZXhhbXBsZS1hcHAtc2VjcmV0
- id: k8s-Auth-Dev2
  redirectURIs:
  - 'https://login-app.ex2.com/ui'
  name: 'Dev Cluster2’
  secret: ZXhhbXBsZS1hcHAtc2VjcmV022
  #trustedPeers:
  # - K8s-Authentication
  - id: k8s-Auth-Dev3
  redirectURIs:
  -  'https://login-app.ex3.com/ui'
   name: 'Dev Cluster3’
  secret: ZXhhbXBsZS1hcHAtc2VjcmV033
  #trustedPeers:
  #- K8s-Authentication

On Dev2 cluster the kube-apiserver yaml

• --oidc-issuer-url='https://dex-app.ex1.com
• --oidc-client-id= k8s-Auth-Dev2
• --oidc-username-claim=email
• --oidc-groups-claim=groups
• --oidc-ca-file= /etc/pki/ca.crt

On Dev3 cluster the kube-apiserver yaml

• --oidc-issuer-url='https://dex-app.ex1.com
• --oidc-client-id= k8s-Auth-Dev3
• --oidc-username-claim=email
• --oidc-groups-claim=groups
• --oidc-ca-file= /etc/pki/ca.crt

Are there extra or anything on the same config needs to be changed

Where does kubectl store the refresh tokens?

As a workaround, I've set up https://syncthing.net/ to sync ~/.kube/config between clients that reuse the same login token, but still get the refresh token conflict.

As a workaround, for OIDC connector, mapping userIDKey to jti claim inside connector config seems to do the trick for now. This will probably cause a lot of entries to be stored, but flushing the DB storage periodically should mitigate the issue.

      id: oidc
      name: OIDC
      config:
        issuer: $DEX_CONNECTOR_ISSUER
        clientID: $DEX_CONNECTOR_CLIENT_ID
        clientSecret: $DEX_CONNECTOR_CLIENT_SECRET
        redirectURI: $DEX_CONNECTOR_REDIRECT_URI
        scopes:
          - email
          - groups
          - offline_access
        getUserInfo: true
        userIDKey: jti # Workaround to support multiple user_id/client_id pairs concurrently
        userNameKey: user_displayname
        insecureEnableGroups: true```