1. Overview

When WIPO DAS forwards a document retrieval request to an office of first filing (OFF), the request must be authenticated using an OAuth2 bearer token. Two authentication setups are supported:

Option 1 – WIPO authorization server (recommended for new offices): WIPO obtains a token from its own OpenAM OAuth2 server and forwards it with the request. The receiving office validates the token against WIPO's published JWKS endpoint. No OAuth2 infrastructure is required on the office side.

Option 2 – Mutual authorization server: The office operates its own OAuth2 server. WIPO queries that server to obtain a token before forwarding requests. This is the model currently used with USPTO.

For offices beginning a new DAS REST API integration, option 1 is recommended as it minimises infrastructure requirements on the office side.
2. Authentication flow

The sequence below describes option 1, where WIPO's OpenAM server issues the token.

1. 
    Token request: WIPO sends a client credentials request to the WIPO OpenAM endpoint, using a client key registered specifically for connections to the target office. OpenAM returns a JWT access token:

   {
     "access_token": "eyJ0eXAiOiJKV1QiLC...<token string>",
     "scope": "das-api/office-exchange",
     "token_type": "Bearer",
     "expires_in": 3599
   }

2. 
    Request forwarding: WIPO forwards the document retrieval request to the office's endpoint, including the token in the HTTP Authorization header as a bearer token:

   Authorization: Bearer eyJ0eXAiOiJKV1QiLC...<token string>

3. 
    

   Token validation: Upon receiving the request, the office validates the token by fetching WIPO's JWKS endpoint and verifying the token signature. See section 3 for the full validation procedure.

3. Token validation using JWKS

JWKS (JSON Web Key Set) is a standard format (RFC 7517) for publishing the public keys used to sign JWT tokens. The office must validate every incoming token against WIPO's JWKS before processing the request.
3.1 Decode the token header

Extract the kid (key ID) and alg fields from the JWT header (the first Base64URL-decoded segment of the token). Example token header:

{
  "typ": "JWT",
  "kid": "lhWqTAfIEkodBo2nUGi3liFJG1U=",
  "alg": "RS256"
}

3.2 Fetch WIPO's JWKS

Retrieve the current key set from WIPO's JWKS URL (see section 5 for environment-specific URLs). The response contains an array of JSON Web Keys:

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "lhWqTAfIEkodBo2nUGi3liFJG1U=",
      "use": "sig",
      "alg": "RS256",
      "x5t": "SX7iI3yi9q5hGy7jPvJmjc5T0vY",
      "x5c": ["MIIE1DCCA7ygAw...<certificate chain>"],
      "n":   "<RSA modulus, Base64URL-encoded>",
      "e":   "AQAB"
    }
  ]
}

3.3 Match the key

Find the JWK entry whose kid value matches the kid from the token header. If no match is found, the token must be rejected. Keys should be cached (respecting HTTP cache headers) to avoid fetching the JWKS on every request; however, if a kid is not found in the cached set, the cache should be refreshed once before rejecting.
3.4 Verify the token signature

Using the matched JWK's public key material (n and e for RSA, or the certificate from x5c), verify the token's signature using the algorithm specified in alg (currently RS256). Standard JWT libraries handle this step natively once the matching JWK is provided.
3.5 Validate token claims

After the signature check, validate the standard JWT claims:

• exp — token must not be expired
• iat — issued-at time should be in the past
• scope — must include das-api/office-exchange
• iss — issuer should match the expected WIPO OpenAM issuer URL

Most JWT libraries (e.g. jsonwebtoken for Node.js, PyJWT for Python, nimbus-jose-jwt for Java) accept a JWKS URI directly and handle key fetching, matching, and signature verification automatically. Manual key parsing is rarely necessary.
4. JWKS field reference

5. Environments & endpoints