Coder powers secure, scalable development across key industries — automotive, finance, government, and technology — enabling faster builds, tighter compliance, and seamless AI adoption in enterprise-grade cloud environments.
This page covers security guidance and current limitations.
OAuth2 provider: how to turn on the provider and create an application
Security considerations
Use HTTPS: Always use HTTPS in production to protect tokens in transit
Implement PKCE: PKCE is mandatory for all authorization code clients (public and confidential)
Validate redirect URLs: Only register trusted redirect URIs.
Dangerous schemes (javascript:, data:, file:, ftp:) are blocked by the control plane, custom URI schemes for native apps (myapp://) are permitted, and public clients additionally cannot use mailto:, tel:, or sms:
Rotate secrets: Periodically rotate client secrets using the management API
Rate limits: every /oauth2 endpoint and both /.well-known discovery endpoints draw on the login rate limit of 60 requests per minute.
Each endpoint counts on its own, so a caller that exhausts one can still reach the others.
Requests with no Coder session are counted per IP address, and the rest are counted per user.
A caller over the limit receives HTTP 429 with a temporarily_unavailable error body.
The limit is fixed.
Running the deployment with --dangerous-disable-rate-limits turns it off, and a user with the Owner role can bypass it on a single request with the X-Coder-Bypass-Ratelimit header
Refresh tokens are not self-sufficient: a confidential client must present its client_secret to refresh or revoke, so a leaked token alone cannot mint new access tokens or end another client's session
No CORS on the authorization endpoint: /oauth2/authorize is reached only by browser navigation and sends no CORS headers, as OAuth 2.1 requires.
The token, registration, revocation, and metadata endpoints do allow cross-origin requests so that browser-based clients can call them
Limitations
The current implementation has these limitations:
No client credentials grant support
No device authorization grant support (RFC 8628)
Implicit grant (response_type=token) is not supported; OAuth 2.1 deprecated this flow due to token leakage risks, and a request for it redirects to the registered callback with unsupported_response_type
Limited to opaque access tokens (no JWT support)
An application may register at most 32 redirect URIs of at most 2048 bytes each.
An application that stored a longer list before this limit existed keeps working, but it cannot be saved again until the list fits.
To fix it, send a PUT with a redirect_uris list that fits, as shown under Create an application with the API.
In the web UI, open the application and remove entries from Redirect URIs until the list fits.
A cleartext http:// redirect URI to a host that is not local is rejected.
Earlier versions accepted one through the management API for a confidential application, although Dynamic Client Registration always refused it.
An application that stored one keeps working, but it cannot be saved again until its list uses https:// or a local host, as described under Callback URL schemes.
A redirect URI with a private-use scheme must name a path or an authority, as described under Callback URL schemes.
Dynamic Client Registration accepted the bare form, such as com.example.app:callback, in earlier versions.
A client that registered one can re-register with an accepted form, or an administrator can correct it with the same PUT.
Learn more
Review OAuth2 provider for enabling the provider and creating an application
