Header authentication
Sending authentication
Send HTTP Basic authentication
Proxy providers can send HTTP Basic authentication credentials to the upstream application. To use this behavior, enable Send HTTP-Basic Authentication on the proxy provider and configure the user and password attribute keys.
For example, with HTTP-Basic Username Key set to app_username and HTTP-Basic Password Key set to app_password, set the following attributes on a user or a group that the user is a 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 the username. If the password attribute is not found, the password is empty.
Receiving authentication
By default, when Intercept header authentication is enabled, authentik intercepts the Authorization header. If the Authorization header value is invalid, authentik returns an HTTP 401 error response. Requests without an Authorization header are still redirected to the standard login flow.
If the proxied application requires the Authorization header, disable Intercept header authentication. When this setting is disabled, authentik still tries to interpret the Authorization header and falls back to the default behavior when it cannot interpret the header.
Receiving HTTP Basic authentication
Proxy providers can receive HTTP Basic authentication credentials. The password must be an app password because the credentials are used internally with the OAuth2 machine-to-machine authentication flow.
Access control uses the policies bound to the application being accessed.
If the received credentials are invalid, authentik starts the standard authentication flow. If the credentials are correct, authentik removes the Authorization header to prevent sending the credentials to the proxied application.
We strongly recommend that the client sending requests with HTTP Basic authentication persists the cookies returned by the outpost. Otherwise, every request must be authenticated independently, which increases load on the authentik server and causes a performance impact.
Starting with authentik 2023.2, logging in with the reserved username goauthentik.io/token behaves as if a bearer token was used. The same options as described below apply. This allows token-based authentication for applications that only support basic authentication.
Receiving HTTP Bearer authentication
Proxy providers can receive HTTP Bearer authentication credentials. The token must be a JWT token issued for the proxy provider. The OAuth2 machine-to-machine authentication flow documentation describes this behavior using the client_id value shown in the admin interface. Both static and JWT authentication methods are supported.
Access control uses the policies bound to the application being accessed.
If the received credentials are invalid, authentik starts the standard authentication flow. If the credentials are correct, authentik removes the Authorization header to prevent sending the credentials to the proxied application.
We recommend 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.