habsi/authentik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

website: Flesh out docs split.

Browse Source 
website: Copy files during build.

website: Allow for mixed env builds.

website: Reduce build size.

website: Expose build.

website: Add build memory debugging.

WIP: Disable broken links check to compare memory usage.

website: Update deps.

website: Clean up API paths.

website: Flesh out 3.8 fixes.

Format.

website: Update ignore paths.

Website: Clean up integrations build.

website: Fix paths.

website: Optimize remark.

website: Update deps.

website: Format.

website: Remove linking.

website: Fix paths.

wip: Attempt API only build.

Prep.

Migrate render to runtime. Tidy sidebar.

Clean up templates.

docs: Move directory. WIP

docs: Flesh out split.

website: Fix issue where routes have collisions.
This commit is contained in:
Teffen Ellis
2025-06-17 21:02:38 +02:00
parent b10c795a26
commit 582812b3ec
704 changed files with 5179 additions and 4670 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/topics/users-sources/sources/protocols/kerberos/browser.md Normal file
View File

@ -0,0 +1,43 @@
---
title: Browser configuration for SPNEGO
---
You might need to configure your web browser to allow SPNEGO. Following are the instructions for major browsers.
## Firefox
1. In the address bar of Firefox, type `about:config` to display the list of current configuration options.
2. In the **Filter** field, type `negotiate` to restrict the list of options.
3. Double-click the `network.negotiate-auth.trusted-uris` entry to display the **Enter string value** dialog box.
4. Enter the name of the domain against which you want to authenticate. For example, `.example.com`.
On Windows environments, to automate the deployment of this configuration use a [Group policy](https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows). On Linux or macOS systems, use [policies.json](https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson).
## Chrome
This section applies only for Chrome users on macOS and Linux machines. For Windows, see the instructions below.
1. Make sure you have the necessary directory created by running: `mkdir -p /etc/opt/chrome/policies/managed/`
2. Create a new `/etc/opt/chrome/policies/managed/mydomain.json` file with write privileges limited to the system administrator or root, and include the following line: `{ "AuthServerWhitelist": "*.example.com" }`.
**Note**: if using Chromium, use `/etc/chromium/policies/managed/` instead of `/etc/opt/chrome/policies/managed/`.
To automate the deployment of this configuration use a [Group policy](https://support.google.com/chrome/a/answer/187202).
## Windows / Internet Explorer
Log in to the Windows machine using an account of your Kerberos realm (or administrative domain).
Open Internet Explorer, click **Tools** and then click **Internet Options**. You can also find **Internet Options** using the system search.
1. Click the **Security** tab.
2. Click **Local intranet**.
3. Click **Sites**.
4. Click **Advanced**.
5. Add your domain to the list.
6. Click the **Security tab**.
7. Click **Local intranet**.
8. Click **Custom Level**.
9. Select **Automatic login only in Intranet zone**.
To automate the deployment of this configuration use a [Group policy](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/browsers/administration/how-to-configure-group-policy-preference-settings).

156
docs/topics/users-sources/sources/protocols/kerberos/index.md Normal file
View File

@ -0,0 +1,156 @@
---
title: Kerberos
authentik_preview: true
authentik_version: "2024.10"
---
This source allows users to enroll themselves with an existing Kerberos identity.
## Preparation
The following placeholders are used in this guide:
- `REALM.COMPANY` is the Kerberos realm.
- `authentik.company` is the FQDN of the authentik install.
Examples are shown for an MIT Krb5 KDC system; you might need to adapt them for you Kerberos installation.
There are three ways to use the Kerberos source:
- As a password backend, where users can log in to authentik with their Kerberos password.
- As a directory source, where users are synced from the KDC.
- With SPNEGO, where users can log in to authentik with their [browser](./browser.md) and their Kerberos credentials.
You can choose to use one or several of those methods.
## Common settings
In the authentik Admin interface, under **Directory** -> **Federation and Social login**, create a new source of type Kerberos with these settings:
- Name: a value of your choosing. This name is shown to users if you use the SPNEGO login method.
- Slug: `kerberos`
- Realm: `REALM.COMPANY`
- Kerberos 5 configuration: If you need to override the default Kerberos configuration, you can do it here. See [man krb5.conf(5)](https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html) for the expected format.
- User matching mode: define how Kerberos users get matched to authentik users.
- Group matching mode: define how Kerberos groups (specified via property mappings) get matched to authentik groups.
- User property mappings and group property mappings: see [Source property mappings](../../property-mappings/index.md) and the section below for details.
## Password backend
No extra configuration is required. Simply select the Kerberos backend in the password stage of your flow.
Note that this only works on users that have been linked to this source, i.e. they must have been created via sync or via SPNEGO.
## Sync
The sync process uses the [Kerberos V5 administration system](https://web.mit.edu/kerberos/krb5-latest/doc/admin/database.html) to list users. Your KDC must support it to sync users with this source.
You need to create both a principal (a unique identity that represents a user or service in a Kerberos network) for authentik and a keytab file:
```bash
$ kadmin
> add_principal authentik/admin@REALM.COMPANY
> ktadd -k /tmp/authentik.keytab authentik/admin@REALM.COMPANY
> exit
$ cat /tmp/authentik.keytab | base64
$ rm /tmp/authentik.keytab
```
In authentik, configure these extra options:
- Sync users: enable it
- Sync principal: `authentik/admin@REALM.COMPANY`
- Sync keytab: the base64-encoded keytab created above.
If you do not wish to use a keytab, you can also configure authentik to authenticate using a password, or an existing credentials cache.
## SPNEGO
You need to create both a principal (a unique identity that represents a user or service in a Kerberos network) for authentik and a keytab file:
```bash
$ kadmin
> add_principal HTTP/authentik.company@REALM.COMPANY
> ktadd -k /tmp/authentik.keytab HTTP/authentik.company@REALM.COMPANY
> exit
$ cat /tmp/authentik.keytab | base64
$ rm /tmp/authentik.keytab
```
In authentik, configure these extra options:
- SPNEGO keytab: the base64-encoded keytab created above.
If you do not wish to use a keytab, you can also configure authentik to use an existing credentials cache.
You can also override the SPNEGO server name if needed.
You might need to configure your web browser to allow SPNEGO. Check out [our documentation](./browser.md) on how to do so. You can now login to authentik using SPNEGO.
### Custom server name
If your authentik instance is accessed from multiple domains, you might want to force the use of a specific server name. You can do so with the **Custom server name** option. The value must be in the form of `HTTP@authentik.company`.
If not specified, the server name defaults to trying out all entries in the keytab/credentials cache until a valid server name is found.
## Extra settings
There are some extra settings you can configure:
- Update internal password on login: when a user logs in to authentik using the Kerberos source as a password backend, their internal authentik password will be updated to match the one from Kerberos.
- Use password writeback: when a user changes their password in authentik, their Kerberos password is automatically updated to match the one from authentik. This is only available if synchronization is configured.
## Kerberos source property mappings
See the [overview](../../property-mappings/index.md) for information on how property mappings work with external sources.
By default, authentik ships with [pre-configured mappings](#built-in-property-mappings) for the most common Kerberos setups. These mappings can be found on the Kerberos Source Configuration page in the Admin interface.
### Built-in property mappings
Kerberos property mappings are used when you define a Kerberos source. These mappings define which Kerberos property maps to which authentik property. By default, the following mappings are created:
- authentik default Kerberos User Mapping: Add realm as group
The realm of the user will be added as a group for that user.
- authentik default Kerberos User Mapping: Ignore other realms
Realms other than the one configured on the source are ignored, and log in is not allowed.
- authentik default Kerberos User Mapping: Ignore system principals
System principals such as `K/M` or `kadmin/admin` are ignored.
- authentik default Kerberos User Mapping: Multipart principals as service accounts
Multipart principals (for example: `HTTP/authentik.company`) have their user type set to **service account**.
These property mappings are configured with the most common Kerberos setups.
### Expression data
The following variable is available to Kerberos source property mappings:
- `principal`: a Python string containing the Kerberos principal. For example `alice@REALM.COMPANY` or `HTTP/authentik.company@REALM.COMPANY`.
When the property mapping is invoked from a SPNEGO context, the following variable is also available:
- `spnego_info`: a Python dictionary with the following keys:
- `initiator_name`: the name of the initiator of the GSSAPI security context
- `target_name`: the name of the target of the GSSAPI security context
- `mech`: the GSSAPI mechanism used. Should always be Kerberos
- `actual_flags`: the flags set on the GSSAPI security context
When the property mapping is invoked from a synchronization context, the following variable is also available:
- `principal_obj`: a [`Principal`](https://kadmin-rs.readthedocs.io/latest/kadmin.html#kadmin.Principal) object retrieved from the KAdmin API
### Additional expression semantics
If you need to skip synchronization for a specific object, you can raise the `SkipObject` exception. To do so, create or modify a Kerberos property mapping to use an expression to define the object to skip.
**Example:**
```python
localpart, realm = principal.rsplit("@", 1)
if localpart == "username":
raise SkipObject
```
## Troubleshooting
You can start authentik with the `KRB5_TRACE=/dev/stderr` environment variable for Kerberos to print errors in the logs.

125
docs/topics/users-sources/sources/protocols/ldap/index.md Normal file
View File

@ -0,0 +1,125 @@
---
title: LDAP Source
---
Sources allow you to connect authentik to an existing user directory. This source allows you to import users and groups from an LDAP Server.
:::info
For Active Directory, follow the [Active Directory Integration](../../directory-sync/active-directory/index.md)
For FreeIPA, follow the [FreeIPA Integration](../../directory-sync/freeipa/index.md)
:::
## Configuration options for LDAP sources
To create or edit a source in authentik, open the Admin interface and navigate to **Directory > Federation and Social login**. There you can create a new LDAP source, or edit an existing one, using the following settings.
- **Enabled**: Toggle this option on to allow authentik to use the defined LDAP source.
- **Update internal password on login**: When the user logs in to authentik using the LDAP password backend, the password is stored as a hashed value in authentik. Toggle off (default setting) if you do not want to store the hashed passwords in authentik.
- **Sync users**: Enable or disable user synchronization between authentik and the LDAP source.
- **User password writeback**: Enable this option if you want to write password changes that are made in authentik back to LDAP.
- **Sync groups**: Enable/disable group synchronization between authentik and the LDAP source.
- **Delete Not Found Objects**: :ak-version[2025.6] This option synchronizes user and group deletions from LDAP sources to authentik. User deletion requires enabling **Sync users** and group deletion requires enabling **Sync groups**.
#### Connection settings
- **Server URI**: URI to your LDAP server/Domain Controller. You can specify multiple servers by separating URIs with a comma, like `ldap://ldap1.company,ldap://ldap2.company`. When using a DNS entry with multiple Records, authentik will select a random entry when first connecting.
- **Enable StartTLS**: Enables StartTLS functionality. To use LDAPS instead, use port `636`.
- **Use Server URI for SNI verification**: this setting is required for servers using TLS 1.3+
- **TLS Verification Certificate**: Specify a keypair to validate the remote certificate.
- **TLS Client authentication certificate**: Client certificate keypair to authenticate against the LDAP Server's Certificate.
- **Bind CN**: CN of the bind user. This can also be a UPN in the format of `user@domain.tld`.
- **Bind Password**: Password used during the bind process.
- **Base DN**: Base DN (distinguished name) used for all LDAP queries.
#### LDAP Attribute mapping
- **User Property Mappings** and **Group Property Mappings**: Define which LDAP properties map to which authentik properties. The default set of property mappings is generated for Active Directory. See also our documentation on [property mappings](#ldap-source-property-mappings).
:::warning
When the **Sync users** and or the **Sync groups** options are enabled, their respective property mapping options must have at least one mapping selected, otherwise the sync will not start.
:::
#### Additional Settings
- **Parent Group**: Parent group for all the groups imported from LDAP. An example use case would be to import Active Directory groups under a root `imported-from-ad` group.
- **User path**: Path template for all new users created.
- **Additional User DN**: Prepended to the base DN for user queries.
- **Additional Group DN**: Prepended to the base DN for group queries.
- **User object filter**: Consider objects matching this filter to be users.
- **Group object filter**: Consider objects matching this filter to be groups.
- **Lookup using a user attribute**: Acquire group membership from a User object attribute (`memberOf`) instead of a Group attribute (`member`). This works with directories with nested groups memberships (Active Directory, RedHat IDM/FreeIPA), using `memberOf:1.2.840.113556.1.4.1941:` as the group membership field.
- **Group membership field**: The user object attribute or the group object attribute that determines the group membership for a user. If **Lookup using a user attribute** is set, this should be a user object attribute, otherwise a group object attribute.
- **User membership attribute**: Attribute name on authentik user objects which is checked against the **Group membership field**. Two common cases are:
- If your groups have `member` attributes containing DNs, set this to `distinguishedName`. (The `distinguishedName` attribute for User objects in authentik is set automatically.)
- If your groups have `memberUid` attributes containing `uid`s, set this to `uid`. Make sure that you've created a property mapping that creates an attribute called `uid`.
- **Object uniqueness field**: This field contains a unique identifier.
## LDAP source property mappings
See the [overview](../../property-mappings/index.md) for information on how property mappings work.
By default, authentik ships with [pre-configured mappings](#built-in-property-mappings) for the most common LDAP setups. These mappings can be found on the LDAP Source Configuration page in the Admin interface.
You can assign the value of a mapping to any user attribute. Keep in mind though, data types from the LDAP server will be carried over. This means that with some implementations, where fields are stored as array in LDAP, they will be saved as array in authentik. To prevent this, use the built-in `list_flatten` function. Here is an example mapping for the user's username and a custom attribute for a phone number:
```python
return {
"username": ldap.get("uid"), # list_flatten is automatically applied to top-level attributes
"attributes": {
"phone": list_flatten(ldap.get("phoneNumber")), # but not for attributes!
},
}
```
### Built-in property mappings
LDAP property mappings are used when you define a LDAP source. These mappings define which LDAP property maps to which authentik property. By default, the following mappings are created:
- `authentik default Active Directory Mapping: givenName`
- `authentik default Active Directory Mapping: sAMAccountName`
- `authentik default Active Directory Mapping: sn`
- `authentik default Active Directory Mapping: userPrincipalName`
- `authentik default LDAP Mapping: mail`
- `authentik default LDAP Mapping: Name`
- `authentik default OpenLDAP Mapping: cn`
- `authentik default OpenLDAP Mapping: uid`
These are configured with most common LDAP setups.
### Expression data
The following variables are available to LDAP source property mappings:
- `ldap`: A Python dictionary containing data from LDAP.
- `dn`: The object DN.
### Additional expression semantics
If you need to skip synchronization for a specific object, you can raise the `SkipObject` exception. To do so, create or modify a LDAP property mapping to use an expression to define the object to skip.
**Example:**
```python
if ldap.get("cn") == "doNotSync":
raise SkipObject
```
## Password login
By default, authentik doesn't update the password it stores for a user when they log in using their LDAP credentials. That means that if the LDAP server is not reachable by authentik, users will not be able to log in. This behavior can be turned on with the **Update internal password on login** setting on the LDAP source.
:::note
Sources created prior to the 2024.2 release have this setting turned on by default.
:::
Be aware of the following security considerations when turning on this functionality:
- Updating the LDAP password does not invalidate the password stored in authentik; however for LDAP Servers like FreeIPA and Active Directory, authentik will lock its internal password during the next LDAP sync. For other LDAP servers, the old passwords will still be valid indefinitely.
- Logging in via LDAP credentials overwrites the password stored in authentik if users have different passwords in LDAP and authentik.
- Custom security measures that are used to secure the password in LDAP may differ from the ones used in authentik. Depending on threat model and security requirements this could lead to unknowingly being non-compliant.
## Troubleshooting
To troubleshoot LDAP sources and their synchronization, see [LDAP Troubleshooting](../../../../troubleshooting/ldap_source.md).

55
docs/topics/users-sources/sources/protocols/oauth/index.mdx Normal file
View File

@ -0,0 +1,55 @@
---
title: OAuth Source
---
This source allows users to enroll themselves with an external OAuth-based Identity Provider. The generic provider expects the endpoint to return OpenID-Connect compatible information. Vendor-specific implementations have their own OAuth Source.
- Policies: Allow/Forbid users from linking their accounts with this provider.
- Request Token URL: This field is used for OAuth v1 implementations and will be provided by the provider.
- Authorization URL: This value will be provided by the provider.
- Access Token URL: This value will be provided by the provider.
- Profile URL: This URL is called by authentik to retrieve user information upon successful authentication.
- Consumer key/Consumer secret: These values will be provided by the provider.
- Scopes: Configure additional scopes to send to the provider.
Starting with authentik 2022.10, the default scopes can be replaced by prefix the value for scopes with `*`.
### OpenID Connect
#### Well-known
Instead of configuring the URLs for a source manually, and the application you're configuring implements the [OpenID Connect Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html), you can configure the source with a single URL. The URL should always end with `.well-known/openid-configuration`. Many applications don't explicitly mention this URL, but for most of them it will be `https://application.company/.well-known/openid-configuration`.
This URL is fetched upon saving the source, and all the URLs will be replaced by the ones from the Discovery document. No automatic re-fetching is done.
#### JWKS
To simplify Machine-to-machine authentication, you can create an OAuth Source as "trusted" source of JWTs. Create a source and configure either the Well-known URL or the OIDC JWKS URL, or you can manually enter the JWKS data if you so desire.
Afterwards, this source can be selected in one or multiple OAuth2 providers, and any JWT issued by any of the configured sources' JWKS will be able to authenticate. To learn more about this, see [JWT-authentication](../../../../add-secure-apps/providers/oauth2/client_credentials#jwt-authentication).
## OAuth source property mappings
See the [overview](../../property-mappings/index.md) for information on how property mappings work.
### Expression data
The following variables are available to OAuth source property mappings:
- `info`: A Python dictionary containing OAuth claims. For example (values might differ depending on the source):
```python
{
"iss": "https://source.company",
"sub": "f153e7da687eec8c8789c72b6cc6bb5197df7b48b263b3151f36908e1bc10691",
"aud": "01e4DmQiG1d3kaewD3Mkz7E7kXknk9j43eZMkNaE",
"aud": "a7809c1b1c4aaa50adfb68660a6273dd9c8d15e4",
"email": "user@authentik.company",
"email_verified": True,
"name": "User",
"given_name": "User",
"preferred_username": "user",
"nickname": "user",
}
```
- `client`: An OAuth client object to make requests to the Source with authentication built-in.
- `token`: A Python dictionary containing OAuth tokens.

93
docs/topics/users-sources/sources/protocols/saml/index.md Normal file
View File

@ -0,0 +1,93 @@
---
title: SAML Source
---
This source allows authentik to act as a SAML Service Provider. Just like the SAML Provider, it supports signed requests. Vendor-specific documentation can be found in the Integrations Section.
## Terminology
| Abbreviation | Name | Description |
| ------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| IDP | Identity Provider | The authoritative SAML authentication source that holds the user database |
| SP | Service Provider | The client which is connected to an IDP, usually providing a service (e.g. a web application). In the current context, authentik is the SP. |
| - | Assertion | A message sent by the IDP asserting that the user has been identified |
| ACS | Assertion Consumer Service | The service on the SP side that consumes the assertion sent from the IDP |
| SSO URL | Single Sign-On URL | The URL on the IDP side which the SP calls to initiate an authentication process |
| SLO URL | Single Log-Out URL | The URL on the IDP side which the SP calls to invalidate a session and logout the user from the IDP as well as the SP |
## Example configuration
If you have the provider metadata, you should be able to extract all values you need from this. There is an example provided for a basic IDP metadata file below.
| Name | Example | Description |
| -------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Name | Company SAML | The name of the authentication source |
| Slug | company-saml | The slug used in URLs for the source |
| SSO URL | https://saml.company/login/saml | The SingleSignOnService URL for the IDP, this can be found in the metadata or IDP documentation. There can be different URLs for different Binding Types (e.g. HTTP-Redirect and HTTP-POST), use the URL corresponding to the binding type you choose below |
| SLO URL | https://saml.company/logout/saml | The URL that is called when a user logs out of authentik, can be used to automatically log the user out of the SAML IDP after logging out of Authentik. Not supported by all IDPs, and not always wanted behaviour. |
| Issuer/Entity ID | https://authentik.company | The identifier for the authentik instance in the SAML federation, can be chosen freely. This is used to identify the SP on the IDP side, it usually makes sense to configure this to the URL of the SP or the path corresponding to the SP (e.g. `/source/saml/<source-slug>/` |
| Binding Type | HTTP-POST | How authentik communicates with the SSO URL (302 redirect or POST request). This will depend on what the provider supports. |
| Allow IDP-Initiated Logins | False | Whether to allow the IDP to log users into authentik without any interaction. Activating this may constitute a security risk since this request is not verified, and could be utilised by an attacker to authenticate a user without interaction on their side. |
| NameID Policy | Persistent | Depending on what the IDP sends as persistent ID, some IDPs use the username or email address while others will use a random string/hashed value. If the user in authentik receives a random string as a username, try using Email address or Windows |
| Flow settings | Default | If there are custom flows in your instance for external authentication, change to use them here |
## Adding authentik as a server provider with your IDP
This will depend heavily on what software you are using for your IDP. On the Metadata tab in the SAML Federation Source you can download the metadata for the service provider, this should enable you to import this into most IDPs. If this does not work, the important parts are:
- Entity ID: Taken from the Issuer/Entity ID field above
- Return URL/ACS URL: `https://authentik.company/source/saml/<source-slug>/acs/`
- Certificate: If you have chosen to sign your outgoing requests, use the public side of the certificate that you specified in the settings
## Example IDP metadata
```xml
<md:EntityDescriptor entityID="https://saml.company/idp">
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
<md:NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</md:NameIDFormat>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</md:NameIDFormat>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
</md:NameIDFormat>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://saml.company/login/saml/"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://saml.company/login/saml/"/>
</md:IDPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">Example Organization</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">Example Organization</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en">http://www.company</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="technical">
<md:Company>Example Organization</md:Company>
<md:GivenName>John</md:GivenName>
<md:SurName>Doe</md:SurName>
<md:EmailAddress>john.doe@company</md:EmailAddress>
<md:TelephoneNumber>012 345 67890</md:TelephoneNumber>
</md:ContactPerson>
<md:ContactPerson contactType="support">
<md:Company>Example Organization</md:Company>
<md:GivenName>Helpdesk</md:GivenName>
<md:SurName>Support</md:SurName>
<md:EmailAddress>helpdesk@company</md:EmailAddress>
<md:TelephoneNumber>012 345 67890</md:TelephoneNumber>
</md:ContactPerson>
</md:EntityDescriptor>
```
## SAML source property mappings
See the [overview](../../property-mappings/index.md) for information on how property mappings work.
### Expression data
The following variables are available to SAML source property mappings:
- `root`: An XML `ETree` object containing data from the source.
- `name_id`: An XML `Element` object identifying the user.

74
docs/topics/users-sources/sources/protocols/scim/index.md Normal file
View File

@ -0,0 +1,74 @@
---
title: SCIM Source
---
The SCIM source allows other applications to directly create users and groups within authentik. SCIM provides predefined schema for users and groups, with a RESTful API, to enable automatic user provisioning and deprovisioning, SCIM is supported by applications such as Microsoft Entra ID, Google Workspace, and Okta.
The base SCIM URL is in the format of `https://authentik.company/source/scim/<source-slug>/v2`. Authentication is done via Bearer tokens that are generated by authentik. When an SCIM source is created, a service account is created and a matching token is provided.
## First steps
To set up an SCIM source, log in as an administrator into authentik. Navigate to **Directory->Federation & Social login**, and click on **Create**. Select the **SCIM Source** type, and give the source a name.
After the source is created, click on the name of the source in the list, and you will see the **SCIM Base URL** which is used by the SCIM client. Use the **Click to copy token** button to copy the token which is used by the client to authenticate SCIM requests.
## Supported Options & Resource types
### `/v2/Users`
Endpoint to list, create, update and delete users.
### `/v2/Groups`
Endpoint to list, create, update and delete groups.
There is also the `/v2/ServiceProviderConfig` and `/v2/ResourceTypes`, which is used by SCIM-enabled applications to find out which features authentik supports.
## SCIM source property mappings
See the [overview](../../property-mappings/index.md) for information on how property mappings work.
### Expression data
Each top level SCIM attribute is available as a variable in the expression. For example given an SCIM request with the payload of
<!-- prettier-ignore-start -->
```json
{
"schemas": [
"urn:scim:schemas:core:2.0",
"urn:scim:schemas:extension:enterprise:2.0"
],
"userName": "foo.bar",
"name": {
"familyName": "bar",
"givenName": "foo",
"formatted": "foo.bar"
},
"emails": [
{
"value": "foo.bar@authentik.company",
"type": "work",
"primary": true
}
],
"title": "",
"urn:scim:schemas:extension:enterprise:2.0": {
"department": ""
}
}
```
<!-- prettier-ignore-end -->
The following variables are available in the expression:
- `schemas` as a list of strings
- `userName` as a string
- `name` as a dictionary
- `emails` as a dictionary
- `title` as a string
- `urn_scim_schemas_extension_enterprise_2_0` as a dictionary
:::info
Top-level keys which include symbols not allowed in python syntax are converted to `_`.
:::