3.4 KiB
| title |
|---|
| Header authentication |
Sending authentication
Send HTTP Basic authentication
Proxy providers have the option to Send HTTP-Basic Authentication to the upstream authentication. When the option in the provider is enabled, two attributes must be specified. These attributes are the keys of values which can be saved on a user or group level that contain the credentials.
For example, with HTTP-Basic Username Key set to app_username and HTTP-Basic Password Key set to app_password, these attributes would have to be set either on a user or a group the user is member of:
app_username: admin
app_password: admin-password
These credentials are only retrieved when the user authenticates to the proxy.
If the user does not have a matching attribute, authentik falls back to using the user's email address as username, and the password will be empty if not found.
Receiving authentication
By default, when the proxy provider receives credentials that aren't valid for itself, it will start a normal authentication flow, and redirect to the flow start page. Some applications might require a 401 response to prompt for credentials.
To always return a 401 response when authentication headers are missing/invalid, you can either set the X-Authentik-No-Redirect header to any value or the query parameter x-authentik-no-redirect to any value.
This is the default behaviour as some applications use the Authorization header for themselves, and as such if the proxy provider would check it, these applications would be inaccessible.
Receiving HTTP Basic authentication
:::info Requires authentik 2023.1 :::
Proxy providers can receive HTTP basic authentication credentials. The password is expected to be an App password, as the credentials are used internally with the OAuth2 machine-to-machine authentication flow.
Access control is done with the policies bound to the application being accessed.
If the received credentials are invalid, a normal authentication flow is initiated. If the credentials are correct, the Authorization header is removed to prevent sending the credentials to the proxied application.
:::danger It is strongly recommended that the client sending requests with HTTP-Basic authentication persists the cookies returned by the outpost. If this is not the case, every request must be authenticated independently, which will increase load on the authentik server and encounter a performance hit. :::
Receiving HTTP Bearer authentication
:::info Requires authentik 2023.1 :::
Proxy providers can receive HTTP bearer authentication credentials. The token is expected to be a JWT token issued for the proxy provider. This is described here, using the client_id value shown in the admin interface. Both static and JWT authentication methods are supported.
Access control is done with the policies bound to the application being accessed.
If the received credentials are invalid, a normal authentication flow is initiated. If the credentials are correct, the Authorization header is removed to prevent sending the credentials to the proxied application.
:::caution It is recommended that the client sending requests with HTTP-Bearer authentication persists the cookies returned by the outpost. For bearer authentication this has a smaller impact than for Basic authentication, but each request is still verified with the authentik server. :::