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
The current implementation of the revokeRefresh endpoint restricts its usage to the user initiating the request, as it is necessary to include the userID (proto and base64 encoded userID:connID) in the request. Unfortunately, the userID that is part of the listPasswords response is not the same as required for the revokeRefresh request. Thus, revoking tokens for any other locally managed user is only possible if logged in.
While it might be feasible to generate the required id based on the user id and connector id, this process should be handled internally and is not something an external tenant should manage, as the implementation could change at any point
The main usecase is to successfully manage all generated users / passwords without doing guesswork or the need to log into each account.
Proposed Solution
Revoking a token becomes essential, particularly following a password change. Therefore, it should be sufficiant to add an option within the updatePassword endpoint to forcefully revoke all associated tokens.
This can be optional to keep the current behavior.
Alternatives Considered
As an alternative to the proposed solution above, it might be enough to change the revokeRefresh to accept both the "real" userID and connID without the need to encode these.
Additional Information
We're happy to contribute this feature!
The text was updated successfully, but these errors were encountered:
@MrDeerly Thanks for opening the issue. It does make sense, but such a logic should be implemented outside of existing API calls. We may add a new one, but we must consider it carefully.
The alternative is more interesting. Could you please elaborate on the problem? What do you mean by encoding and real?
A few word about our use case:
We use OIDC providers for real human user authz. For some parts of our system we sadly have to rely on password grants using the local connector. The local connector basically contains service accounts that can be fully managed by certain human users.
When offboarding a human users it might become necessary to change the credentials and revoke all refresh tokens of a service account (password in the dex world).
--
The revokeRefresh endpoint currently requires the sub, which can only be known when logged into the desired account. The sub itself is proto and base64 encoded.
The problem is that the ListPasswords endpoint only returns Email, Username, UserID, while the UserID cannot be used in the revokeRefresh req.
While i understand your concerns about changing the behavior of an existing endpoint, this could be implemented non-breaking, by making the new option optional. E.g. the updatePassword endpoint could become a optional revokePassword param.
Changing the behavior of revokePassword would come with an breaking change because we would need to switch the required sub against the email or userID.
Another possible non-breaking solution might be to return the sub as part of the listPasswords req. All information required for encoding sub (userID and connectorID) are known.
Preflight Checklist
Problem Description
The current implementation of the
revokeRefresh
endpoint restricts its usage to the user initiating the request, as it is necessary to include the userID (proto and base64 encodeduserID:connID
) in the request. Unfortunately, the userID that is part of thelistPasswords
response is not the same as required for therevokeRefresh
request. Thus, revoking tokens for any other locally managed user is only possible if logged in.While it might be feasible to generate the required id based on the user id and connector id, this process should be handled internally and is not something an external tenant should manage, as the implementation could change at any point
The main usecase is to successfully manage all generated users / passwords without doing guesswork or the need to log into each account.
Proposed Solution
Revoking a token becomes essential, particularly following a password change. Therefore, it should be sufficiant to add an option within the
updatePassword
endpoint to forcefully revoke all associated tokens.This can be optional to keep the current behavior.
Alternatives Considered
As an alternative to the proposed solution above, it might be enough to change the
revokeRefresh
to accept both the "real" userID and connID without the need to encode these.Additional Information
We're happy to contribute this feature!
The text was updated successfully, but these errors were encountered: