* initial implementation Signed-off-by: Jens Langhammer <jens@goauthentik.io> * check for openid/profile claims Signed-off-by: Jens Langhammer <jens@goauthentik.io> * include jwks sources in proxy provider Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add web ui for jwks Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only show sources with JWKS data configured Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix introspection tests Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start basic Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add docs, update admonitions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add client_id to api, add tab for auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens Langhammer <jens@goauthentik.io>
2.7 KiB
title |
---|
Header 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 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. :::