- IETF RFC 6794 Section 1.4: Opaque access tokens
- IETF RFC 6819 Section 5.1.4.1.3: No Cleartext Storage of Credentials
- IETF RFC 6819 Section 5.1.4.1.4: Encryption of Credentials
- IETF RFC 6819 Section 5.1.5.2: Determine Expiration Time
- IETF RFC 6819 Section 5.1.5.3: Use Short Expiration Time
- IETF RFC 6819 Section 5.1.5.8: Bind Token to Client id
- IETF RFC 6819 Section 5.2.4.4: Binding of Authorization "code" to "client_id"
- IETF RFC 6819 Section 5.2.4.5: Binding of Authorization "code" to "redirect_uri"
- IETF RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
Authorization codes, and access tokens are generated by generating 32 bytes using a cryptographically-secure PRNG, and passing it through HMAC-SHA256 with a secret key that is kept in the authorization server. The randomly-generated bytes and MAC are then individually BASE64-URL-encoded with no padding, and concatenated together with a "." delimiter.
base64_url_no_padding(prng_bytes).base64_url_no_padding(hmac_sha256(prng_bytes, secret_key))
All OAuth 2.0 client secrets are bcrypt-hashed with a cost of 10. The server supports client credentials being passed
through either the HTTP Authorization header, or through the request body in the case the endpoint being queried
supports being queried with url-encoded form data as a request body.
OAuth 2.0 Implicit Flow and Resource Owner Password Credentials Flow are intentionally not going to be supported as they are strongly advised against being used by recent IETF RFCs and several many identity providers.