GHSA-w6p7-2fxx-4f44 Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions
OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group RestrictionsSummaryThe `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:**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.**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.**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 supportRoot Cause`createTokenFromRefreshToken` (oidc_service.go:451-547) performs the following checks on a refresh request:Verify the signed refresh token JWT (line 457) -- **checked**Verify client credentials (line 467) -- **checked**Look up stored refresh token by hash, expiry, user_id, client_id (line 478-495) -- **checked**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**Whether `IsUserGroupAllowedToAuthorize` passes for group-restricted clients -- **MISSING** (groups are loaded at line 481 via `Preload("User.UserGroups")` but never validated)Meanwhile, `RevokeAuthorizedClient` (line 1445-1471) only deletes the `UserAuthorizedOidcClient` record. It does not delete associated `OidcRefreshToken` records. There is no FK cascade between these tables (the FK cascade on `oidc_refresh_tokens` is only on user DELETE and client DELETE, not on authorization record deletion).Proof of Concept (Verified Live)Tested against Pocket ID HEAD (626adbf) running in Docker with e2etest build. All 20 test assertions pass.Variant 1: Authorization Revocation Bypass**Live output**: Introspection confirms `active: true`. ID token contains: `name: Tim Cook, email: tim.cook@test.com, groups: [designers, developers]`.Variant 2: Disabled User Bypass**Impact**: The admin kill switch for terminating employee access is completely bypassed. A fired employee's pre-existing OIDC refresh tokens continue to grant access to all downstream services.Variant 3: Group Restriction BypassImpactThe three variants share the same root cause but have different real-world implications:**Authorization revocation is ineffective**: Users who revoke an OIDC client's access have a false sense of security. A malicious or compromised client retains indefinite access to the user's identity data through token rotation. The id_token issued during refresh contains full PII (name, email, groups, custom claims) regardless of the userinfo endpoint's authorization check.**Account disabling does not terminate OIDC access**: This is the highest-severity variant. When an organization terminates an employee and disables their Pocket ID account, all session-based access is correctly blocked. But any OIDC client that obtained a refresh token before the disabling continues to have full access. In enterprise environments where Pocket ID gates access to sensitive services (Git, CI/CD, infrastructure), this creates a persistent backdoor.**Group-based access control is only enforced at authorization time**: Group restrictions on OIDC clients (e.g., "only the infrastructure team can access the CI/CD client") can be bypassed by anyone who obtained a refresh token before being removed from the group.RelatedGitHub issue #1390 reports a similar pattern: refresh tokens are not deleted when a session ends via the end-session endpoint. Same root cause (refresh token lifecycle detached from authorization state), different entry point.Suggested FixPrimary fix: Re-validate authorization state in createTokenFromRefreshTokenAdd the following checks after the refresh token lookup (after line 495):Secondary fix: Delete refresh tokens on authorization revocationIn `RevokeAuthorizedClient`, also delete all refresh tokens for the user-client pair:Both fixes should be applied together (defense in depth).Self-Review**Is this by-design?** No. The revocation feature, the disabled flag, and group restrictions all exist to control access. The refresh flow bypassing all three is a bug, not a feature.**Are there upstream bounds?** No. Refresh tokens are stored independently. No FK cascade, no periodic cleanup, no validation of authorization state.**Honest weaknesses**:Variant 1 (revocation): The attacker must be the OIDC client operator (they need client credentials and existing refresh token). Userinfo endpoint does return 404 after revocation, which is a partial mitigation. But the id_token issued during refresh already contains all PII.All variants: Requires a pre-existing refresh token, so the access must have been legitimately granted at some point.**Existing reports**: Issue #1390 covers the related end-session case. No prior security reports for the revocation/disabled/group variants.Koda Reef
CVSS v4.0 score: 8.5