Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
5.9 KiB
OpenID Connect
The following steps through how to integrate any OpenID Connect provider (Okta, Active Directory, etc.) to Coder.
Step 1: Set Redirect URI with your OIDC provider
Your OIDC provider will ask you for the following parameter:
- Redirect URI: Set to
https://coder.domain.com/api/v2/users/oidc/callback
Step 2: Configure Coder with the OpenID Connect credentials
Set the following environment variables on your Coder deployment and restart Coder:
CODER_OIDC_ISSUER_URL="https://issuer.corp.com"
CODER_OIDC_EMAIL_DOMAIN="your-domain-1,your-domain-2"
CODER_OIDC_CLIENT_ID="533...des"
CODER_OIDC_CLIENT_SECRET="G0CSP...7qSM"
OIDC Claims
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_LOG_FILTER=".*got oidc claims.*" 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.
Note
If you need to ensure that Coder only uses information from the ID token and does not hit the UserInfo endpoint, you can set the configuration option
CODER_OIDC_IGNORE_USERINFO=true.
Email Addresses
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.
Note
If this field is not present, Coder will attempt to use the claim field configured for
usernameas an email address. If this field is not a valid email address, OIDC logins will fail.
Email Address Verification
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:
CODER_OIDC_IGNORE_EMAIL_VERIFIED=true
Note
This will cause Coder to implicitly treat all OIDC emails as "verified", regardless of what the upstream identity provider says.
Usernames
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.
Note
If this claim is empty, the email address will be stripped of the domain, and become the username (e.g.
example@coder.combecomesexample). To avoid conflicts, Coder may also append a random word to the resulting username.
OIDC Login Customization
If you'd like to change the OpenID Connect button text and/or icon, you can configure them like so:
CODER_OIDC_SIGN_IN_TEXT="Sign in with Gitea"
CODER_OIDC_ICON_URL=https://gitea.io/images/gitea.png
To change the icon and text above the OpenID Connect button, see application name and logo url in appearance settings.
Configure Refresh Tokens
By default, OIDC access tokens typically expire after a short period. This is typically after one hour, but varies by provider.
Without refresh tokens, users will be automatically logged out when their access token expires.
Follow Configure OIDC Refresh Tokens for provider-specific steps.
The general steps to configure persistent user sessions are:
-
Configure your Coder OIDC settings:
For most providers, add the
offline_accessscope:CODER_OIDC_SCOPES=openid,profile,email,offline_accessFor Google, add auth URL parameters (
CODER_OIDC_AUTH_URL_PARAMS) too:CODER_OIDC_SCOPES=openid,profile,email CODER_OIDC_AUTH_URL_PARAMS='{"access_type": "offline", "prompt": "consent"}' -
Configure your identity provider to issue refresh tokens.
-
After configuration, have users log out and back in once to obtain refresh tokens
Important
Misconfigured refresh tokens can lead to frequent user authentication prompts.
Disable Built-in Authentication
To remove email and password login, set the following environment variable on your Coder deployment:
CODER_DISABLE_PASSWORD_AUTH=true
SCIM
Important
SCIM is a Premium feature (learn more).
Coder's SCIM 2.0 implementation is not a fully certified or guaranteed implementation of the SCIM 2.0 specification. It is intended to cover common user provisioning and deprovisioning flows with the major identity providers (Okta, Microsoft Entra ID, etc.). Specific attributes, endpoints, or behaviors required by your IdP may not be supported, and compatibility may change between releases. If you depend on a specific SCIM behavior, contact us before rolling it out broadly. See coder/coder#15830 for tracked gaps and ongoing work.
Coder supports user provisioning and deprovisioning via SCIM 2.0 with header authentication. Upon deactivation, users are suspended and are not deleted. Configure your SCIM application with an auth key and supply it the Coder server.
CODER_SCIM_AUTH_HEADER="your-api-key"
TLS
If your OpenID Connect provider requires client TLS certificates for authentication, you can configure them like so:
CODER_TLS_CLIENT_CERT_FILE=/path/to/cert.pem
CODER_TLS_CLIENT_KEY_FILE=/path/to/key.pem