Skip to content

Conversation

@fioan89
Copy link
Collaborator

@fioan89 fioan89 commented Oct 13, 2025

Recent versions of Coder act as an OAuth 2.1 authorization server for first- and third‑party applications.
This PR aims at providing support for authenticating via OAuth with Coder Toolbox and still retain backward compatibility for authentication via API tokens or via certificates.

This PR is a WIP:

  • Infrastructure code to discover if a Coder deployment supports OAuth2
  • Infrastructure code to discover the Coder OAuth2 endpoints
  • Infrastructure code to dynamically register Coder Toolbox as a client app
  • Toolbox API is configured so that authorization page can be launched
  • Token refresh is configured as well
  • The infrastructure for exchanging the authorization codes for tokens and handle of auth redirect URI
  • Add support for PKCE verification
  • Limit the permission scope to read workspaces, read templates, template versions, buildinfo, read/write workspace, agents + apps, read your own user details, authentication, read access to SSH keys
  • Retrieve the logged account
  • Update/Redesign the Login wizard screen to skip over the token step if OAuth is available
  • Offer an optional link with text to the effect of, “Can’t authenticate? Generate a token” that will reload the page with a generated token if clicked.
  • Integrate with Coder CLI, authenticate the CLI with OAuth2 as well.
  • Update documentation

fioan89 added 11 commits October 9, 2025 22:52
Toolbox API comes with a basic oauth2 client. This commit
sets-up details about two important oauth flows:

- authorization flow, in which the user is sent to web page
  where an authorization code is generated which is exchanged
  for an access token.
- details about token refresh endpoint where users can obtain
  a new access token and a new refresh token.

A couple of important aspects:
- the client app id is resolved in upstream
- as well as the actual endpoints for authorization and token refresh
- S256 is the only code challenge supported
…ation url

OAuth endpoint `.well-known/oauth-authorization-server` provides metadata about
the endpoint for dynamic client registration and supported response types.
This commit adds support for deserializing these values.
OAuth allows programatic client registration for apps like Coder Toolbox
via the DCR endpoint which requires a name for the client app, the requested
scopes, redirect URI, etc... DCR replies back with a similar structure but
in addition it returs two very important properties: client_id - a unique
client identifier string and also a client_secret - a secret string value
used by clients to authenticate to the token endpoint.
Code Toolbox plugin should protect against authorization code interception
attacks by making use of the PKCE security extension which involves
a cryptographically random string (128 characters) known as code verifier
and a code challenge - derived from code verifier using the S256 challenge method.
The OAuth2-compatible authentication manager provided by Toolbox
- authentication and token endpoints are now passed via the login configuration object
- similar for client_id and client_secret
- PCKE is now enabled
…injection

- remove ServiceLocator dependency from CoderToolboxContext
- move OAuth manager creation to CoderToolboxExtension for cleaner separation
- Refactor CoderOAuthManager to use configuration-based approach instead of constructor injection

The idea behind these changes is that createRefreshConfig API does not receive a configuration
object that can provide the client id and secret and even the refresh url. So initially
we worked around the issue by passing the necessary data via the constructor. However this approach
means a couple of things:

- the actual auth manager can be created only at a very late stage, when a URL is provided by users
- can't easily pass arround the auth manager without coupling the components
- have to recreate a new auth manager instance if the user logs out and logs in to a different URL
- service locator needs to be passed around because this is the actual factory of oauth managers in Toolbox

Instead, we went with a differet approach, COderOAuthManager will derive and store the refresh configs once
the authorization config is received. If the user logs out and logs in to a different URL the refresh data is
also guaranteed to be updated. And on top of that - this approach allows us to get rid of all of the issues
mentioned above.
Toolbox can handle automatically the exchange of an authorization code with a token
by handling the custom URI for oauth. This commit calls the necessary API
in the Coder Toolbox URI handling.
@fioan89 fioan89 requested review from f0ssel and jcjiang October 14, 2025 21:23
@fioan89 fioan89 changed the title impl: support for OAuth2 impl: support for OAuth2 [WIP] Oct 14, 2025
POST /api/v2/oauth2-provider/apps is actually for manual admin
registration for admin created apps. Programmatic Dynamic Client
Registration is done via `POST /oauth2/register`.

At the same time I included `registration_access_token` and `registration_client_uri`
to use it later in order to refresh the client secret without re-registering the client app.
A bunch of code thrown around to launch the OAuth flow.
Still needs a couple of things:
- persist the client id and registration uri and token
- re-use client id instead of re-register every time
- properly handle scenarios where OAuth is not available
- the OAuth right now can be enabled if we log out and then
hit next in the deployment screen
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant