docs: add more specific steps and information about oidc refresh tokens (#18336)

closes https://github.com/coder/coder/issues/18307

relates to https://github.com/coder/coder/pull/18318

preview:
-
[refresh-tokens](https://coder.com/docs/@18307-refresh-tokens/admin/users/oidc-auth/refresh-tokens)
-
[configuring-okta](https://coder.com/docs/@18307-refresh-tokens/tutorials/configuring-okta)
~(not sure why @Emyrk 's photo is so huge there though)~ ✔️
- [x] removed from
[idp-sync](https://coder.com/docs/@18307-refresh-tokens/admin/users/idp-sync)

to do:
- move keycloak
- add ping federate and azure
- edit text (possibly placeholders for now - I want to see how it all
relates and edit it again. right now, there's a note about the same
thing in every section in way that's not super helpful/necessary)
- ~convert some paragraphs to OL~ calling this out of scope for now

---------

Co-authored-by: EdwardAngert <17991901+EdwardAngert@users.noreply.github.com>
This commit is contained in:
Edward Angert
2025-06-16 13:18:55 -04:00
committed by GitHub
parent 095007766b
commit 5c16079aff
19 changed files with 362 additions and 117 deletions

View File

@ -25,7 +25,7 @@ credentials are stolen.
### User authentication
Configure [OIDC authentication](../../admin/users/oidc-auth.md) against your
Configure [OIDC authentication](../../admin/users/oidc-auth/index.md) against your
organizations Identity Provider (IdP), such as Okta, to allow single-sign on.
1. Enable and require two-factor authentication in your identity provider.

View File

@ -20,9 +20,9 @@ authorization. This can be achieved by using the Git provider, such as GitHub,
as an authentication method. If you don't know how to do that, we have written
documentation to help you:
- [GitHub](../admin/external-auth.md#github)
- [GitLab self-managed](../admin/external-auth.md#gitlab-self-managed)
- [Self-managed git providers](../admin/external-auth.md#self-managed-git-providers)
- [GitHub](../admin/external-auth/index.md#github)
- [GitLab self-managed](../admin/external-auth/index.md#gitlab-self-managed)
- [Self-managed git providers](../admin/external-auth/index.md#self-managed-git-providers)
With the authentication in place, it is time to set up the template to use the
[Git Clone module](https://registry.coder.com/modules/git-clone) from the

View File

@ -6,7 +6,7 @@
<span style="vertical-align:middle;">Steven Masley</span>
</a>
</div>
December 13, 2023
Updated: June, 2025
---
@ -15,7 +15,7 @@ Sign On (SSO) on Coder.
To configure custom claims in Okta to support syncing roles and groups with
Coder, you must first have setup an Okta application with
[OIDC working with Coder](../admin/users/oidc-auth.md).
[OIDC working with Coder](../admin/users/oidc-auth/index.md).
From here, we will add additional claims for Coder to use for syncing groups and
roles.
@ -28,38 +28,39 @@ If the Coder roles & Coder groups can be inferred from
Okta has a simple way to send over the groups as a `claim` in the `id_token`
payload.
In Okta, go to the application Sign On settings page.
In Okta, go to the application **Sign On** settings page.
Applications > Select Application > General > Sign On
**Applications** > **Select Application** > **General** > **Sign On**
In the OpenID Connect ID Token section, turn on Groups Claim Type and set
the Claim name to `groups`. Optionally configure a filter for which groups to
be sent.
In the **OpenID Connect ID Token** section, turn on **Groups Claim Type** and set
the **Claim name** to `groups`.
Optionally, configure a filter for which groups to be sent.
> [!IMPORTANT]
> If the user does not belong to any groups, the claim will not be sent. Make
> sure the user authenticating for testing is in at least one group. Defer to
> [troubleshooting](../admin/users/index.md) with issues.
> If the user does not belong to any groups, the claim will not be sent.
> Make sure the user authenticating for testing is in at least one group.
![Okta OpenID Connect ID Token](../images/guides/okta/oidc_id_token.png)
Configure Coder to use these claims for group sync. These claims are present in
the `id_token`. See all configuration options for group sync in the
[docs](https://coder.com/docs/admin/auth#group-sync-enterprise).
Configure Coder to use these claims for group sync.
These claims are present in the `id_token`.
For more group sync configuration options, consult the [IDP sync documentation](../admin/users/idp-sync.md#group-sync).
```bash
# Add the 'groups' scope.
CODER_OIDC_SCOPES=openid,profile,email,groups
# Add the 'groups' scope and include the 'offline_access' scope for refresh tokens
CODER_OIDC_SCOPES=openid,profile,email,offline_access,groups
# This name needs to match the "Claim name" in the configuration above.
CODER_OIDC_GROUP_FIELD=groups
```
> [!NOTE]
> The `offline_access` scope is required in Coder v2.23.0+ to prevent hourly session timeouts.
These groups can also be used to configure role syncing based on group
membership.
membership:
```bash
# Requires the "groups" scope
CODER_OIDC_SCOPES=openid,profile,email,groups
CODER_OIDC_SCOPES=openid,profile,email,offline_access,groups
# This name needs to match the "Claim name" in the configuration above.
CODER_OIDC_USER_ROLE_FIELD=groups
# Example configuration to map a group to some roles
@ -69,32 +70,32 @@ CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}'
## (Easy) Mapping Okta profile attributes
If roles or groups cannot be completely inferred from Okta group memberships,
another option is to source them from a users attributes. The user attribute
list can be found in Directory > Profile Editor > User (default).
another option is to source them from a user's attributes.
The user attribute list can be found in **Directory** > **Profile Editor** > **User (default)**.
Coder can query an Okta profile for the application from the `/userinfo` OIDC
endpoint. To pass attributes to Coder, create the attribute in your application,
Coder can query an Okta profile for the application from the `/userinfo` OIDC endpoint.
To pass attributes to Coder, create the attribute in your application,
then add a mapping from the Okta profile to the application.
Directory > Profile Editor > {Your Application} > Add Attribute
**Directory** > **Profile Editor** > {Your Application} > **Add Attribute**
Create the attribute for the roles, groups, or both. **Make sure the attribute
is of type `string array`.**
Create the attribute for the roles, groups, or both. Make sure the attribute
is of type `string array`:
![Okta Add Attribute view](../images/guides/okta/add_attribute.png)
On the Okta User to {Your Application} tab, map a `roles` or `groups`
attribute you have configured to the application.
On the **Okta User to {Your Application}** tab, map a `roles` or `groups`
attribute you have configured to the application:
![Okta Add Claim view](../images/guides/okta/add_claim.png)
Configure using these new attributes in Coder.
Configure using these new attributes in Coder:
```bash
# This must be set to false. Coder uses this endpoint to grab the attributes.
CODER_OIDC_IGNORE_USERINFO=false
# No custom scopes are required.
CODER_OIDC_SCOPES=openid,profile,email
# Include offline_access for refresh tokens
CODER_OIDC_SCOPES=openid,profile,email,offline_access
# Configure the group/role field using the attribute name in the application.
CODER_OIDC_USER_ROLE_FIELD=approles
# See our docs for mapping okta roles to coder roles.
@ -104,56 +105,86 @@ CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}'
# CODER_OIDC_GROUP_FIELD=...
```
> [!NOTE]
> The `offline_access` scope is required in Coder v2.23.0+ to prevent hourly session timeouts.
## (Advanced) Custom scopes to retrieve custom claims
Okta does not support setting custom scopes and claims in the default
authorization server used by your application. If you require this
functionality, you must create (or modify) an authorization server.
authorization server used by your application.
If you require this functionality, you must create (or modify) an authorization server.
To see your custom authorization servers go to Security > API”. Note the
`default` authorization server **is not the authorization server your app is
using.** You can configure this default authorization server, or create a new
one specifically for your application.
To see your custom authorization servers go to **Security** > **API**.
Note the `default` authorization server is not the authorization server your app is using.
You can configure this default authorization server, or create a new one specifically for your application.
Authorization servers also give more refined controls over things such as
token/session lifetimes.
Authorization servers also give more refined controls over things such as token/session lifetimes.
![Okta API view](../images/guides/okta/api_view.png)
To get custom claims working, we should map them to a custom scope. Click the
authorization server you wish to use (likely just using the default).
To get custom claims working, map them to a custom scope.
Click the authorization server you wish to use (likely just using the default).
Go to Scopes, and Add Scope”. Feel free to create one for roles, groups, or
both.
Go to **Scopes**, and **Add Scope**.
Feel free to create one for roles, groups, or both:
![Okta Add Scope view](../images/guides/okta/add_scope.png)
Now create the claim to go with the said scope. Go to “Claims”, then “Add
Claim”. Make sure to select **ID Token** for the token type. The **Value**
expression is up to you based on where you are sourcing the role information.
Lastly, configure it to only be a claim with the requested scope. This is so if
other applications exist, we do not send them information they do not care
about.
Create the claim to go with the said scope.
Go to **Claims**, then **Add Claim**.
Make sure to select **ID Token** for the token type.
The **Value** expression is up to you based on where you are sourcing the role information.
Configure it to only be a claim with the requested scope.
This is so if other applications exist, we do not send them information they do not care about:
![Okta Add Claim with Roles view](../images/guides/okta/add_claim_with_roles.png)
Now we have a custom scope + claim configured under an authorization server, we
need to configure coder to use this.
Now we have a custom scope and claim configured under an authorization server.
Configure Coder to use this:
```bash
# Grab this value from the Authorization Server > Settings > Issuer
# DO NOT USE the application issuer URL. Make sure to use the newly configured
# authorization server.
CODER_OIDC_ISSUER_URL=https://dev-12222860.okta.com/oauth2/default
# Add the new scope you just configured
CODER_OIDC_SCOPES=openid,profile,email,roles
# Add the new scope you just configured and offline_access for refresh tokens
CODER_OIDC_SCOPES=openid,profile,email,roles,offline_access
# Use the claim you just configured
CODER_OIDC_USER_ROLE_FIELD=roles
# See our docs for mapping okta roles to coder roles.
CODER_OIDC_USER_ROLE_MAPPING='{"admin-group":["template-admin","user-admin"]}'
```
You can use the “Token Preview” page to verify it has been correctly configured
> [!NOTE]
> The `offline_access` scope is required in Coder v2.23.0+ to prevent hourly session timeouts.
You can use the "Token Preview" page to verify it has been correctly configured
and verify the `roles` is in the payload.
![Okta Token Preview](../images/guides/okta/token_preview.png)
## Troubleshooting
### Users Are Logged Out Every Hour
**Symptoms**: Users experience session timeouts approximately every hour and must re-authenticate
**Cause**: Missing `offline_access` scope in `CODER_OIDC_SCOPES`
**Solution**:
1. Add `offline_access` to your `CODER_OIDC_SCOPES` configuration
1. Restart your Coder deployment
1. All existing users must logout and login once to receive refresh tokens
### Refresh Tokens Not Working After Configuration Change
**Symptoms**: Hourly timeouts, even after adding `offline_access`
**Cause**: Existing user sessions don't have refresh tokens stored
**Solution**: Users must logout and login again to get refresh tokens stored in the database
### Verify Refresh Token Configuration
To confirm that refresh tokens are working correctly:
1. Check that `offline_access` is included in your `CODER_OIDC_SCOPES`
1. Verify users can stay logged in beyond Okta's access token lifetime (typically one hour)
1. Monitor Coder logs for any OIDC refresh errors during token renewal

View File

@ -171,7 +171,7 @@ resource "coder_agent" "main" {
Because Docker is running locally in the Coder server, there is no need to
authenticate `coder_agent`. But if your `coder_agent` is running on a remote
host, your template will need
[authentication credentials](../admin/external-auth.md).
[authentication credentials](../admin/external-auth/index.md).
This template's agent also runs a startup script, sets environment variables,
and provides metadata.
@ -181,7 +181,7 @@ and provides metadata.
- Installs [code-server](https://coder.com/docs/code-server), a browser-based
[VS Code](https://code.visualstudio.com/) app that runs in the workspace.
We'll give users access to code-server through `coder_app`, later.
We'll give users access to code-server through `coder_app` later.
- [`env` block](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#env)