OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions

Summary

The createTokenFromRefreshToken function (oidc_service.go:451) validates the refresh token's cryptographic integrity but does not re-validate the user's current authorization state before issuing new tokens. This allows three bypasses:

1. Authorization revocation bypass: After a user revokes an OIDC client's authorization, the client can continue refreshing tokens indefinitely because RevokeAuthorizedClient does not delete associated refresh tokens, and the refresh flow does not check if the authorization record still exists.

2. Disabled user bypass: After an admin disables a user account, pre-existing refresh tokens continue to work because the OIDC token endpoint does not check user.Disabled. Session-based access is properly blocked by auth middleware, but the OIDC refresh path bypasses it entirely.

3. Group restriction bypass: After removing a user from an OIDC client's allowed user groups, the refresh token continues to work because createTokenFromRefreshToken does not call IsUserGroupAllowedToAuthorize.

Each refresh rotates the token with a fresh 30-day expiry, enabling perpetual access.

Target

• Repository: pocket-id/pocket-id
• Version: HEAD (626adbf), also affects v2.5.0 and all versions with refresh token support

Root Cause

createTokenFromRefreshToken (oidc_service.go:451-547) performs the following checks on a refresh request:

1. Verify the signed refresh token JWT (line 457) -- checked
2. Verify client credentials (line 467) -- checked
3. Look up stored refresh token by hash, expiry, user_id, client_id (line 478-495) -- checked
4. Verify refresh token belongs to the requesting client (line 498) -- checked

It does NOT check:

• Whether a UserAuthorizedOidcClient record still exists for the user-client pair -- MISSING
• Whether user.Disabled is false -- MISSING -...