a714c781a6
website/docs: Reduce redundant usage of badges. Move badge logic to components. - Fix JSX class name warning. - Remove duplicate titles. - Flesh out `support_level` frontmatter.
88 lines
4.2 KiB
Plaintext
88 lines
4.2 KiB
Plaintext
## Machine-to-machine authentication
|
|
|
|
Client credentials can be used for machine-to-machine communication authentication. Clients can authenticate themselves using service-accounts; standard client_id + client_secret is not sufficient. This behavior is due to providers only being able to have a single secret at any given time.
|
|
|
|
Note that authentik does treat a grant type of `password` the same as `client_credentials` to support applications which rely on a password grant.
|
|
|
|
### Static authentication
|
|
|
|
Hence identification is based on service-accounts, and authentication is based on App-password tokens. These objects can be created in a single step using the _Create Service account_ function.
|
|
|
|
An example request can look like this:
|
|
|
|
```http
|
|
POST /application/o/token/ HTTP/1.1
|
|
Host: authentik.company
|
|
Content-Type: application/x-www-form-urlencoded
|
|
|
|
grant_type=client_credentials&
|
|
client_id=application_client_id&
|
|
username=my-service-account&
|
|
password=my-token&
|
|
scope=profile
|
|
```
|
|
|
|
This will return a JSON response with an `access_token`, which is a signed JWT token. This token can be sent along requests to other hosts, which can then validate the JWT based on the signing key configured in authentik.
|
|
|
|
Starting with authentik 2024.4, it is also possible to encode the username and token of the user to authenticate with, separated with a colon, into a base64 string and pass it as `client_secret` value.
|
|
|
|
In addition to that, with authentik 2024.4 it is also possible to pass the configured `client_secret` value, which will automatically generate a service account user for which the JWT token will be issued.
|
|
|
|
### JWT-authentication
|
|
|
|
#### Externally issued JWTs
|
|
|
|
You can authenticate and get a token using an existing JWT. For readability we will refer to the JWT issued by the external issuer/platform as input JWT, and the resulting JWT from authentik as the output JWT.
|
|
|
|
To configure this, define a JWKS URL/raw JWKS data in OAuth Sources. If a JWKS URL is specified, authentik will fetch the data and store it in the source, and then select the source in the OAuth2 Provider that will be authenticated against.
|
|
|
|
With this configuration, any JWT issued by the configured sources' certificates can be used to authenticate:
|
|
|
|
```http
|
|
POST /application/o/token/ HTTP/1.1
|
|
Host: authentik.company
|
|
Content-Type: application/x-www-form-urlencoded
|
|
|
|
grant_type=client_credentials&
|
|
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
|
|
client_assertion=$inputJWT&
|
|
client_id=application_client_id
|
|
```
|
|
|
|
Alternatively, you can set the `client_secret` parameter to `$inputJWT`, for applications that can set the password from a file but not other parameters.
|
|
|
|
Input JWTs are checked to verify that they are signed by any of the selected _Federated OIDC Sources_, and that their `exp` attribute is not set as now or in the past.
|
|
|
|
To dynamically limit access based on the claims of the tokens, you can use _[Expression policies](../../../customize/policies/expression.mdx)_:
|
|
|
|
```python
|
|
return request.context["oauth_jwt"]["iss"] == "https://my.issuer"
|
|
```
|
|
|
|
#### authentik-issued JWTs:ak-version[2024.12]
|
|
|
|
To allow federation between providers, modify the provider settings of the application (whose token will be used for authentication) to select the provider of the application to which you want to federate.
|
|
|
|
With this configuration, any JWT issued by the configured providers can be used to authenticate:
|
|
|
|
```
|
|
POST /application/o/token/ HTTP/1.1
|
|
Host: authentik.company
|
|
Content-Type: application/x-www-form-urlencoded
|
|
|
|
grant_type=client_credentials&
|
|
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
|
|
client_assertion=$inputJWT&
|
|
client_id=application_client_id
|
|
```
|
|
|
|
Alternatively, you can set the `client_secret` parameter to the `$inputJWT`, for applications which can set the password from a file but not other parameters.
|
|
|
|
Input JWTs must be valid access tokens issued by any of the configured _Federated OIDC Providers_, they must not have been revoked and must not have expired.
|
|
|
|
To dynamically limit access based on the claims of the tokens, you can use _[Expression policies](../../../customize/policies/expression.mdx)_:
|
|
|
|
```python
|
|
return request.context["oauth_jwt"]["iss"] == "https://my.issuer"
|
|
```
|