...
Requirements/Notes/Considerations
Each point in this section will be fleshed out with reasoning, pros, cons, etc. and then consolidated once confident in what’s necessaryThis section contains an explanation of each requirement for supporting OAuth 2 public clients in Synapse. This section is summarized at the top of this document, and services are enumerated at the bottom of this document.
PKCE
Best practices suggest that authorization servers are required to support PKCE [2][3]. PKCE only provides benefits to public OAuth clients, since a malicious app must have knowledge of an OAuth client’s credentials to execute the attack.PKCE would require clients to generate a code and send a hash of the code to Synapse when initiating the authorization code OAuth flow. When redeeming the authorization code, the client must send the original code. Synapse would then hash the code and verify that the hash matches the initial hash sent by the client. must have knowledge of an OAuth client’s credentials to execute the attack.
For more details, expand the following section:
| Expand | ||
|---|---|---|
| ||
PKCE prevents a malicious application from hijacking an authorization code. This can occur when using a native app’s OAuth client, and the redirect URI is compromised by a malicious application observing traffic to the user agent (mobile app or web browser). In this scenario, the malicious app has the authorization code, and is in possession of the client’s credentials (if they exist), because it is a public client. Thus the malicious app now has access to the user’s account. With PKCE, the client generates a high-entropy random string, and calculates the SHA256 hash of the string. When making the initial authorization request, the hash is sent to the authorization server. The authorization server associates the hash with the authorization code, before sending it to the client (the hash may be embedded in the authorization code) When a client uses the authorization code, they must provide the initial random string. The authorization server computes the SHA256 hash of the string, and will only issue token(s) to the client if the hashes match. |
...
Use of an expired refresh token invalidates the active refresh token
...
refresh token
The following would only apply to public OAuth clients because the refresh token acts as a bearer token. The goal is to reduce the risk and impact of token theft/replay attacks.
OAuth 2.1 ([2]) Note on refresh tokens for public clients:
...
We will use refresh token rotation because it is partially implemented (we currently do not revoke an active token if an expired token is used). We can extend our implementation to include this the missing behavior.
Token binding is also more complicatedcomplicated, so we won’t use it. For details, expand the following section.
...
Endpoint | Request Body | Response Body | Notes/Modifications | New Service? |
|---|---|---|---|---|
OAuthClient extended to require a new field | ❌ | |||
None | Do not generate client secrets for public clients. | ❌ | ||
OIDCAuthorizationRequest extended to include | ❌ | |||
Multiple parameters | Additional request parameter | ❌ | ||
Multiple parameters | Client secret not required if the client ID is a public client. | ❌ | ||
Multiple parameters | If a public client uses an expired/rotated refresh token, revoke the current ‘version’ of the refresh token (e.g. refresh token is | ❌ | ||
- | - | Restrict client 0 from using these endpointsusing these endpoints (this is already the case, but it is unclear if it is explicit). | ❌ |
Support for first-party command line public clients
...
Endpoint | Request Body | Response Body | Notes | New Service? |
|---|---|---|---|---|
N/A | N/A | N/A | Add a bootstrapped ‘Synapse Command Line’ OAuth client. We use a new client and not client 0 for two reasons
| ❌ |
POST /oauth2/userGeneratedToken | OIDCTokenGenerationRequest {
} | OIDCTokenResponse | Generates a token response that users can copy and paste into the command line client. Effectively replaces API keys. In most cases, the | ✅ |
...