Authentication management
By default, Coder enables built-in authentication, though you can change this if desired.
To do so, go to Manage > Users. Find the user whose authentication type you want to change, and use the Auth Type to toggle between Built-In and OpenID Connect.
If you opt for OpenID Connect, you'll need to provide additional configuration steps, which are detailed in the subsequent sections of this article.
Coder's OIDC claims
Coder will request the scopes openid
, email
, and profile
from your OIDC
provider.
Coder expects the following OIDC claims from your OIDC provider:
-
email
(required) -
name
(full name/display name) -
preferred_username
(username for dev URLs)
If the name
or email
claims are not present in the identity token returned
from your OIDC provider, Coder will request these from the user-info
endpoint
of your OIDC provider. If hitting this endpoint is problematic, ensure that your
OIDC provider returns these claims in the tokens it provides.
You may need to map these to your existing claims within your OIDC provider's
admin console. If name
and preferred_username
are not provided, Coder will
derive both claims from the email address.
Set up OIDC authentication
To set up OIDC authentication, you'll first need to register a Coder application
with your OIDC provider. During this process, you'll be asked to provide a
domain name for the OIDC token callback; use
https://coder.my-company.com/oidc/callback
.
Once you've registered a Coder application with your OIDC provider, you'll need to return to Coder and complete the setup process. Under Admin > Manage > Authentication, ensure that you've selected OpenID Connect as the authentication type. Then, provide the following parameters:
- Client ID: The client ID for the Coder application you registered with the OIDC provider
- Client Secret: The secret assigned to the Coder application you registered with the OIDC provider
- Issuer (e.g.,
https://my-idp.com/realm/my-org
): The URL where Coder can find your OIDC provider's configuration document
If you do not have values for any of these parameters, you can obtain them from your OIDC provider.
There are several additional configuration parameters that may be of interest to you:
- Enable Access Tokens: Toggle On if you'd like to allow users to fetch
tokens from
https://<yourDomain>/api/v0/users/me/oidc-access-token
- Additional Scopes: Specify any scopes (beyond the default) that you would
like Coder to request from the authentication provider. By default, Coder
requests the scopes
openid
,email
, andprofile
. Consult your authentication provider's documentation for information on which scopes they support. - Disable built-in authentication: Choose whether Coder removes the ability to log in with an email/password option when you've enabled OIDC authentication
Logging
If you're having issues with your OIDC configuration, you can enable additional logging of OIDC tokens to aid in troubleshooting.
To do so, update your Helm chart and set
the OIDC_DEBUG
environment variable to true
:
coderd:
extraEnvs:
- name: "OIDC_DEBUG"
value: "true"
Troubleshooting OIDC failures
If OIDC fails to configure, only an admin using the built-in authentication can go into the settings and resolve the issue. All users using OIDC to authenticate will be unable to login until it is fixed.
The admin must follow the Set up OIDC authentication steps again. Once the OIDC authentication is fixed, it is recommended to restart the coderd deployment.
Disable built-in authentication
You can disable built-in authentication as an option for accessing Coder if you have OIDC configured.
To do so, navigate to Manage > Admin > Authentication. Then, toggle Disable built-in authentication to On and click Save preferences.
Site managers can still use built-in authentication. The Admin Login option will be visible on the login page if built-in authentication is disabled.