Threats tagged 'ghsa-q4xm-p75h-h9p3'

## Summary The client credentials grant (`grant_type=client_credentials`) does not validate the resource parameter before embedding it as the aud claim in the issued JWT. Any authenticated OIDC client can obtain a Pocket ID-signed access token claiming authorization for any arbitrary audience, including other registered OIDC clients. There is no check that the requested audience is a registered resource server, and no check that the requesting client has been granted permission to access it. ## Details In `backend/internal/service/oidc_service.go`, `createTokenFromClientCredentials` accepts the resource parameter from the token request and places it directly into the `aud` claim of the issued JWT without validation: ```golang audClaim := client.ID if input.Resource != "" { audClaim = input.Resource // no validation performed } accessToken, err := s.jwtService.GenerateOAuthAccessToken(dummyUser, audClaim) ``` The only guard in this function is `verifyClientCredentialsInternal`, which confirms the requesting client's credentials are valid. After that check passes, any value supplied as resource is accepted. There is no registry of permitted audiences, no per-client authorization policy controlling which resources a client may request tokens for, and no validation that the resource value corresponds to anything registered in Pocket ID. The introspection endpoint (`/api/oidc/introspect`) does not mitigate this. It checks that the introspecting client's ID matches the token's `aud` claim, but since the attacker controls `aud`, a resource server calling introspection to validate an inbound token will receive `"active": true`. Pocket ID has no server-side record of which client requested the token or whether it was authorized to do so, so introspection cannot distinguish a legitimately issued token from one obtained through this vulnerability. ## PoC Given a Pocket ID instance with two registered OIDC clients — `client-a` (attacker-controlled) and `client-b` (target resource) — the following request causes Pocket ID to issue a signed JWT with `aud: ["client-b"]`, authenticated only as `client-a`: ``` curl -X POST https://<pocket-id-host>/api/oidc/token \ -d "grant_type=client_credentials" \ -d "client_id=client-a" \ -d "client_secret=<client-a-secret>" \ -d "resource=client-b" ``` The response is a valid, Pocket ID-signed JWT with: ```json { "sub": "client-client-a", "aud": ["client-b"], "iss": "https://<pocket-id-host>", "type": "oauth-access-token" } ``` This token will pass signature and `aud` validation at any resource server that trusts Pocket ID's JWKS and accepts `client-b` as its audience identifier. ## Impact Any OIDC client registered in Pocket ID that has valid credentials (client secret or federated identity) can obtain a Pocket ID-signed access token scoped to any other registered client or arbitrary audience string. In deployments where services use the client credentials grant and validate incoming bearer tokens against Pocket ID's JWKS, this allows a compromised or malicious client to bypass audience-based access controls and present tokens to resource servers it should not be authorized to access. The severity depends on deployment: if no resource servers validate Pocket ID-issued access tokens, there is no immediate exploitable impact. In deployments that do rely on the client credentials grant for service-to-service authorization, the isolation between services is entirely broken.