API: Revoke refreshTokens when updating password

[MrDeerly]

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

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!

[nabokihms]

@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?

[MrDeerly]

Hey @nabokihms, thanks for looking into this.

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.

I hope that helps to understand the issue