providers/proxy: add setting to intercept authorization header (#4457)
* add setting to intercept authorization header Signed-off-by: Jens Langhammer <jens@goauthentik.io> * rename to intercept_header_auth Signed-off-by: Jens Langhammer <jens@goauthentik.io> Signed-off-by: Jens Langhammer <jens@goauthentik.io>
This commit is contained in:
@ -21,11 +21,9 @@ If the user does not have a matching attribute, authentik falls back to using th
|
||||
|
||||
## 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.
|
||||
By default, when _Intercept header authentication_ is enabled, authentik will intercept the authorization header. If the authorization header value is invalid, an error response will be shown with a 401 status code. Requests without an authorization header will still be redirected to the standard login flow.
|
||||
|
||||
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.
|
||||
If the proxied application requires usage of the "Authorization" header, the setting should be disabled. When this setting is disabled, authentik will still attempt to interpret the "Authorization" header, and fall back to the default behaviour if it can't.
|
||||
|
||||
### Receiving HTTP Basic authentication
|
||||
|
||||
|
Reference in New Issue
Block a user