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
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
We are trying to use DEX as an IDP federation layer, A large number of applications and trusted middleware/internal systems use DEX for Authn and fetching user info. Some of these internal/middleware systems don't interact with users directly and rely on token exchange (machine-machine auth) with dex itself (configuring dex itself as its upstream) along with trusted peer to generate downstream tokens for middlewares and internal systems (in conjunction with trusted peer).
However in this setup if we enable public clients, we run into an issue that public clients can perform token exchange to get new token using already obtained token... In a way opening-up access forever.
Proposed Solution
I think if we can add an optional feature to disable/block token-exchange (machine-machine auth) for clients using a specific list of connectors it can address this limitation. This way we can block token exchange request for client.
if slices.Contains(client.DisableTokenExchangeWith, connID) {
errMsg := fmt.Sprintf("Token exchange with %s is disabled for client %s", connID, client.ID)
s.tokenErrHelper(w, errInvalidRequest, errMsg, http.StatusBadRequest)
return
}
Alternatives Considered
Alternatively, if exchanged token have the same expiry as that of subject token presented it could also probably resolve this access extension.
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
We are trying to use DEX as an IDP federation layer, A large number of applications and trusted middleware/internal systems use DEX for Authn and fetching user info. Some of these internal/middleware systems don't interact with users directly and rely on token exchange (machine-machine auth) with dex itself (configuring dex itself as its upstream) along with trusted peer to generate downstream tokens for middlewares and internal systems (in conjunction with trusted peer).
However in this setup if we enable public clients, we run into an issue that public clients can perform token exchange to get new token using already obtained token... In a way opening-up access forever.
Proposed Solution
I think if we can add an optional feature to disable/block token-exchange (machine-machine auth) for clients using a specific list of connectors it can address this limitation. This way we can block token exchange request for client.
Alternatives Considered
Alternatively, if exchanged token have the same expiry as that of subject token presented it could also probably resolve this access extension.
Additional Information
No response
The text was updated successfully, but these errors were encountered: