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:

  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:

{
    "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.