.

By default, Coder is accessible via password authentication. Coder does not

recommend using password authentication in production, and recommends using an

authentication provider with properly configured multi-factor authentication

(MFA). It is your responsibility to ensure the auth provider enforces MFA

correctly.

The following steps explain how to set up GitHub OAuth or OpenID Connect.

First,

[register a GitHub OAuth app](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/).

GitHub will ask you for the following Coder parameters:

- **Homepage URL**: Set to your Coder deployments

[`CODER_ACCESS_URL`](../cli/server.md#--access-url) (e.g.

`https://coder.domain.com`)

- **User Authorization Callback URL**: Set to `https://coder.domain.com`

Note the Client ID and Client Secret generated by GitHub. You will use these

values in the next step.

Coder will need permission to access user email addresses. Find the "Account

Permissions" settings for your app and select "read-only" for "Email addresses".

Navigate to your Coder host and run the following command to start up the Coder

server:

coder server --oauth2-github-allow-signups=true --oauth2-github-allowed-orgs="your-org" --oauth2-github-client-id="8d1...e05" --oauth2-github-client-secret="57ebc9...02c24c"

Alternatively, if you are running Coder as a system service, you can achieve the

same result as the command above by adding the following environment variables

to the `/etc/coder.d/coder.env` file:

**Note:** To allow everyone to signup using GitHub, set:

Once complete, run `sudo service coder restart` to reboot Coder.

If deploying Coder via Helm, you can set the above environment variables in the

`values.yaml` file as such:

coder:

env:

- name: CODER_OAUTH2_GITHUB_ALLOW_SIGNUPS

value: "true"

- name: CODER_OAUTH2_GITHUB_CLIENT_ID

value: "533...des"

- name: CODER_OAUTH2_GITHUB_CLIENT_SECRET

value: "G0CSP...7qSM"

# If setting allowed orgs, comment out CODER_OAUTH2_GITHUB_ALLOW_EVERYONE and its value

- name: CODER_OAUTH2_GITHUB_ALLOWED_ORGS

value: "your-org"

# If allowing everyone, comment out CODER_OAUTH2_GITHUB_ALLOWED_ORGS and it's value

#- name: CODER_OAUTH2_GITHUB_ALLOW_EVERYONE

# value: "true"

To upgrade Coder, run:

helm upgrade <release-name> coder-v2/coder -n <namespace> -f values.yaml

The following steps through how to integrate any OpenID Connect provider (Okta,

Active Directory, etc.) to Coder.

Your OIDC provider will ask you for the following parameter:

- **Redirect URI**: Set to `https://coder.domain.com/api/v2/users/oidc/callback`

Navigate to your Coder host and run the following command to start up the Coder

server:

coder server --oidc-issuer-url="https://issuer.corp.com" --oidc-email-domain="your-domain-1,your-domain-2" --oidc-client-id="533...des" --oidc-client-secret="G0CSP...7qSM"

If you are running Coder as a system service, you can achieve the same result as

the command above by adding the following environment variables to the

`/etc/coder.d/coder.env` file:

Once complete, run `sudo service coder restart` to reboot Coder.

If deploying Coder via Helm, you can set the above environment variables in the

`values.yaml` file as such:

coder:

env:

- name: CODER_OIDC_ISSUER_URL

value: "https://issuer.corp.com"

- name: CODER_OIDC_EMAIL_DOMAIN

value: "your-domain-1,your-domain-2"

- name: CODER_OIDC_CLIENT_ID

value: "533...des"

- name: CODER_OIDC_CLIENT_SECRET

value: "G0CSP...7qSM"

When a user logs in for the first time via OIDC, Coder will merge both the

claims from the ID token and the claims obtained from hitting the upstream

provider's `userinfo` endpoint, and use the resulting data as a basis for

creating a new user or looking up an existing user.

To troubleshoot claims, set `CODER_VERBOSE=true` and follow the logs while

signing in via OIDC as a new user. Coder will log the claim fields returned by

the upstream identity provider in a message containing the string

`got oidc claims`, as well as the user info returned.

By default, Coder will look for the OIDC claim named `email` and use that value

for the newly created user's email address.

If your upstream identity provider users a different claim, you can set

`CODER_OIDC_EMAIL_FIELD` to the desired claim.

Coder requires all OIDC email addresses to be verified by default. If the

`email_verified` claim is present in the token response from the identity

provider, Coder will validate that its value is `true`. If needed, you can

disable this behavior with the following setting:

When a new user logs in via OIDC, Coder will by default use the value of the

claim field named `preferred_username` as the the username.

If your upstream identity provider uses a different claim, you can set

`CODER_OIDC_USERNAME_FIELD` to the desired claim.

If you'd like to change the OpenID Connect button text and/or icon, you can

configure them like so:

To change the icon and text above the OpenID Connect button, see application

name and logo url in [appearance](./appearance.md) settings.

To remove email and password login, set the following environment variable on

your Coder deployment:

Coder supports user provisioning and deprovisioning via SCIM 2.0 with header

authentication. Upon deactivation, users are

[suspended](./users.md#suspend-a-user) and are not deleted.

[Configure](./configure.md) your SCIM application with an auth key and supply it

the Coder server.

If your OpenID Connect provider requires client TLS certificates for

authentication, you can configure them like so:

This article walks you through the user roles available in Coder and creating

and managing users.

Coder offers these user roles in the community edition:

| | Auditor | User Admin | Template Admin | Owner |

| ----------------------------------------------------- | ------- | ---------- | -------------- | ----- |

| Add and remove Users | | ✅ | | ✅ |

| Manage groups (enterprise) | | ✅ | | ✅ |

| Change User roles | | | | ✅ |

| Manage **ALL** Templates | | | ✅ | ✅ |

| View **ALL** Workspaces | | | ✅ | ✅ |

| Update and delete **ALL** Workspaces | | | | ✅ |

| Run [external provisioners](./provisioners.md) | | | ✅ | ✅ |

| Execute and use **ALL** Workspaces | | | | ✅ |

| View all user operation [Audit Logs](./audit-logs.md) | ✅ | | | ✅ |

A user may have one or more roles. All users have an implicit Member role that

may use personal workspaces.

A malicious Template Admin could write a template that executes commands on the

host (or `coder server` container), which potentially escalates their privileges

or shuts down the Coder server. To avoid this, run

[external provisioners](./provisioners.md).

In low-trust environments, we do not recommend giving users direct access to

edit templates. Instead, use

[CI/CD pipelines to update templates](../templates/change-management.md) with

proper security scans and code reviews in place.

Coder user accounts can have different status types: active, dormant, and

suspended.

An _active_ user account in Coder is the default and desired state for all

users. When a user's account is marked as _active_, they have complete access to

the Coder platform and can utilize all of its features and functionalities

without any limitations. Active users can access workspaces, templates, and

interact with Coder using CLI.

A user account is set to _dormant_ status when they have not yet logged in, or

have not logged into the Coder platform for the past 90 days. Once the user logs

in to the platform, the account status will switch to _active_.

Dormant accounts do not count towards the total number of licensed seats in a

Coder subscription, allowing organizations to optimize their license usage.

When a user's account is marked as _suspended_ in Coder, it means that the

account has been temporarily deactivated, and the user is unable to access the

platform.

Only user administrators or owners have the necessary permissions to manage

suspended accounts and decide whether to lift the suspension and allow the user

back into the Coder environment. This level of control ensures that

administrators can enforce security measures and handle any compliance-related

issues promptly.

Similar to dormant users, suspended users do not count towards the total number

of licensed seats.

Coder is a self-hosted platform that runs on your own infrastructure. For large deployments, we recommend running the control plane on Kubernetes. Workspaces can be run as VMs or Kubernetes pods. The control plane (`coderd`) runs in a single region. However, workspace proxies, provisioners, and workspaces can run across regions or even cloud providers for the optimal developer experience.

Learn more about Coder's architecture and concepts: [Concepts](./architecture.md)

- [Kubernetes Best Practices](#)