diff --git a/website/docs/add-secure-apps/providers/proxy/__placeholders.md b/website/docs/add-secure-apps/providers/proxy/__placeholders.md index 8c5e20717f..863e298b65 100644 --- a/website/docs/add-secure-apps/providers/proxy/__placeholders.md +++ b/website/docs/add-secure-apps/providers/proxy/__placeholders.md @@ -1,6 +1,6 @@ :::info _example-outpost_ is used as a placeholder for the outpost name. -_authentik.company_ is used as a placeholder for the authentik install. +_authentik.company_ is used as a placeholder for the authentik installation. _app.company_ is used as a placeholder for the external domain for the application. -_outpost.company_ is used as a placeholder for the outpost. When using the embedded outpost, this can be the same as _authentik.company_ +_outpost.company_ is used as a placeholder for the outpost. When using the embedded outpost, this can be the same as _authentik.company_. ::: diff --git a/website/docs/add-secure-apps/providers/proxy/_envoy_istio.md b/website/docs/add-secure-apps/providers/proxy/_envoy_istio.md index ccfb34b32f..37545dcbf0 100644 --- a/website/docs/add-secure-apps/providers/proxy/_envoy_istio.md +++ b/website/docs/add-secure-apps/providers/proxy/_envoy_istio.md @@ -27,7 +27,7 @@ spec: - cookie ``` -Afterwards, you can create _AuthorizationPolicy_ resources to protect your applications like this: +You can then create _AuthorizationPolicy_ resources to protect your applications like this: ```yaml apiVersion: security.istio.io/v1beta1 diff --git a/website/docs/add-secure-apps/providers/proxy/create-proxy-provider.md b/website/docs/add-secure-apps/providers/proxy/create-proxy-provider.md new file mode 100644 index 0000000000..90037a1272 --- /dev/null +++ b/website/docs/add-secure-apps/providers/proxy/create-proxy-provider.md @@ -0,0 +1,97 @@ +--- +title: Create a proxy provider +--- + +For an overview of how proxy providers work, see the [proxy provider](./index.md) documentation. + +## Workflow to create a proxy provider + +Follow this workflow to create and configure a proxy provider: + +1. Create a proxy provider and application pair. +2. Select the proxy provider mode. +3. Assign the application to a proxy outpost. +4. Configure your reverse proxy. +5. Verify access to the application. + +## Create a proxy provider and application pair + +To create a provider along with the corresponding application that uses it for authentication, navigate to **Applications** > **Applications** and click **New Application**. We recommend this combined approach for most common use cases. Alternatively, you can use the legacy method to create only the provider by navigating to **Applications** > **Providers** and clicking **New Provider**. + +1. Log in to authentik as an administrator and open the authentik Admin interface. +2. Navigate to **Applications** > **Applications** and click **New Application**. +3. On the **New application** page, define the application details, and then click **Next**. +4. Select **Proxy Provider** as the **Provider Type**, and then click **Next**. +5. On the **Configure Proxy Provider** page, provide a provider name and select the authorization flow. +6. Configure the provider mode as described below. +7. On the **Review and Submit Application** page, review the settings, and then click **Create Application**. + +## Select the proxy provider mode + +The proxy provider supports three modes. The correct mode depends on where proxying happens and whether one provider protects one application or a whole domain. + +### Proxy + +Use **Proxy** mode when the authentik outpost should act as the reverse proxy. The outpost receives requests on the external host, checks authentication and authorization, and forwards allowed requests to the upstream application. + +Configure the following settings: + +- **External host**: the URL users use to access the protected application. Include the scheme and any non-standard port, for example `https://app.company`. +- **Internal host**: the upstream URL the outpost forwards requests to, for example `http://internal-app:8080`. +- **Internal host SSL Validation**: whether the outpost validates the upstream application's TLS certificate. + +### Forward auth (single application) + +Use **Forward auth (single application)** mode when your existing reverse proxy should proxy traffic to the application and call the authentik outpost only to check authentication and authorization. + +Each protected application needs its own application and provider in authentik. Configure **External host** as the URL users use to access that application. + +### Forward auth (domain level) + +Use **Forward auth (domain level)** mode when one provider should protect multiple applications under the same parent domain. + +Domain-level forward auth reduces the number of providers you need to create, but it cannot enforce different application-level authorization rules for each protected application. + +Configure the following settings: + +- **Authentication URL**: the external URL used for authentication, typically the authentik URL for the protected domain, for example `https://auth.company`. +- **Cookie domain**: the parent domain where the authentication cookie is valid, for example `domain.tld`. + +If your applications run on subdomains such as `app1.domain.tld` and `app2.domain.tld`, set the cookie domain to `domain.tld`. + +## Assign the application to a proxy outpost + +Proxy providers require a proxy outpost. + +For simple deployments, you can use the [embedded outpost](../../outposts/embedded/embedded.mdx), which runs as part of the authentik server. For deployments that need a separate outpost lifecycle, use a managed outpost or manually deploy a proxy outpost. + +1. Navigate to **Applications** > **Outposts**. +2. Select an existing proxy outpost or click **Create**. +3. If you create a new outpost, set **Type** to `Proxy` and select the relevant integration or manual deployment option. +4. Under **Applications**, select the application that uses the proxy provider. +5. Click **Update** or **Create**. + +For more information, see the [Outposts](../../outposts/index.mdx) documentation. + +## Configure your reverse proxy + +The reverse proxy configuration depends on the provider mode: + +- In **Proxy** mode, route the protected external host to the proxy outpost. +- In **Forward auth (single application)** mode, route the application to its upstream service and route `/outpost.goauthentik.io` on the application domain to the proxy outpost. +- In **Forward auth (domain level)** mode, route each protected application to its upstream service and configure the reverse proxy to send authentication checks to the domain-level authentication URL. + +For forward auth configuration examples, see: + +- [nginx](./server_nginx.mdx) +- [Traefik](./server_traefik.mdx) +- [Caddy](./server_caddy.mdx) +- [Envoy](./server_envoy.mdx) + +## Verify access + +Open the protected application URL in your browser. + +If you are not already authenticated, authentik should redirect you to the configured authentication flow. After successful authentication and authorization, authentik redirects you back to the application. + +If access fails, check the outpost logs and search for the proxy provider's `client_id`. The `client_id` is shown on the provider's **Authentication** tab. diff --git a/website/docs/add-secure-apps/providers/proxy/custom_headers.md b/website/docs/add-secure-apps/providers/proxy/custom_headers.md index 4fa39d39f1..1280564180 100644 --- a/website/docs/add-secure-apps/providers/proxy/custom_headers.md +++ b/website/docs/add-secure-apps/providers/proxy/custom_headers.md @@ -2,27 +2,27 @@ title: Custom headers --- -The proxy can send custom headers to your upstream application. These can be configured in one of two ways: +The proxy can send custom headers to your upstream application. Configure these headers in one of two ways: -- Group attributes; this allows for inheritance, but only allows static values -- Property mappings; this allows for dynamic values +- Group or user attributes, which allow static values. +- Property mappings, which allow dynamic values. -## Group attributes +## Group or user attributes -Edit the group or user you wish the header to be set for, and set these attributes: +Edit the group or user that should set the header, and set the following attributes: ```yaml additionalHeaders: X-My-Header: value ``` -You can the add users to this group or override the field in users. +You can then add users to the group or override the field on individual users. -## Property Mappings +## Property mappings -For dynamic Header values (for example, your application requires X-App-User to contain the username), property mappings can be used. +Use property mappings for dynamic header values, for example when an application requires `X-App-User` to contain the username. -Create a new Scope mapping with a name and scope of your choice, and use an expression like this: +Create a new scope mapping with a name and scope of your choice, and use an expression like this: ```python return { @@ -36,6 +36,6 @@ return { } ``` -After you've created this Scope mapping, make sure to edit the proxy provider and select the mapping. +After you create this scope mapping, edit the proxy provider and select the mapping under **Additional scopes**. -As you can see by the similar structure, this just overrides any static attributes, so both of these methods can be combined. +The property mapping uses the same `additionalHeaders` structure as group and user attributes, so both methods can be combined. When both methods set the same header, the property mapping value overrides the static attribute value. diff --git a/website/docs/add-secure-apps/providers/proxy/forward_auth.mdx b/website/docs/add-secure-apps/providers/proxy/forward_auth.mdx index 9bc1136472..70b46100e8 100644 --- a/website/docs/add-secure-apps/providers/proxy/forward_auth.mdx +++ b/website/docs/add-secure-apps/providers/proxy/forward_auth.mdx @@ -2,38 +2,35 @@ title: Forward auth --- -Using forward auth uses your existing reverse proxy to do the proxying, and only uses the authentik outpost to check authentication and authorization. +Forward auth uses your existing reverse proxy for application traffic and relies on the authentik outpost only to check authentication and authorization. -To use forward auth instead of proxying, you have to change a couple of settings. -In the Proxy Provider, make sure to use one of the Forward auth modes. +To use forward auth, select one of the forward auth modes on the proxy provider and configure your reverse proxy to send authentication checks to the outpost. ## Forward auth modes -The only configuration difference between single application mode and domain level mode is the host that you specify. - -For single application, you'd use the domain that the application is running on, and only `/outpost.goauthentik.io` is redirected to the outpost. - -For domain level, you'd use the same domain as authentik. - ### Single application -Single application mode works for a single application hosted on its dedicated subdomain. This lets you keep per-application access policies in authentik. +Single-application mode works for one application hosted on its own domain or subdomain. Set **External host** to the application URL. + +In this mode, only `/outpost.goauthentik.io` on the application domain is routed to the authentik outpost. The application traffic itself continues to be routed to the upstream application by your reverse proxy. + +Use this mode when each application should have its own provider, policies, bindings, and authorization behavior. ### Domain level -To use forward auth instead of proxying, you have to change a couple of settings. -In the Proxy Provider, make sure to use the _Forward auth (domain level)_ mode. +Domain-level mode works for multiple applications under the same parent domain. Set **Authentication URL** to the URL used for authentication, and **Cookie domain** to the parent domain shared by the protected applications. -This mode differs from the _Forward auth (single application)_ mode in the following points: +This mode differs from _Forward auth (single application)_ mode in the following ways: -- You don't have to configure an application in authentik for each domain -- Users don't have to authorize multiple times +- You do not need to configure an application and provider in authentik for each application domain. +- Users do not need to authorize each application separately. +- You cannot restrict individual applications to different users with separate application-level policies. -There are, however, also some downsides, mainly the fact that you **can't** restrict individual applications to different users. +Use single-application mode when each application needs separate access rules. ## Configuration templates -For configuration templates for each web server, refer to the following: +For reverse proxy configuration templates, refer to the following: import DocCardList from "@theme/DocCardList"; diff --git a/website/docs/add-secure-apps/providers/proxy/header_authentication.mdx b/website/docs/add-secure-apps/providers/proxy/header_authentication.mdx index 558e054f70..1506295e84 100644 --- a/website/docs/add-secure-apps/providers/proxy/header_authentication.mdx +++ b/website/docs/add-secure-apps/providers/proxy/header_authentication.mdx @@ -6,9 +6,9 @@ title: Header authentication ### Send HTTP Basic authentication -Proxy providers have the option to _Send HTTP-Basic Authentication_ to the upstream application. 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. +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`, these attributes would have to be set either on a user or a group the user is member of: +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: ```yaml app_username: admin @@ -17,36 +17,36 @@ 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. +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 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. +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 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 behavior if it can't. +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 is expected to be an _App password_, as the credentials are used internally with the [OAuth2 machine-to-machine authentication flow](../oauth2/machine_to_machine.mdx). +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](../oauth2/machine_to_machine.mdx). -Access control is done with the policies bound to the application being accessed. +Access control uses 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. +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. :::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. +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` will behave as if a bearer token was used. All the same options as below apply. This is to allow token-based authentication for applications which might only support basic authentication. +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 is expected to be a JWT token issued for the proxy provider. This is described in the [OAuth2 machine-to-machine authentication flow](../oauth2/machine_to_machine.mdx) documentation, using the _client_id_ value shown in the admin interface. Both static and JWT authentication methods are supported. +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](../oauth2/machine_to_machine.mdx) documentation describes this behavior 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. +Access control uses 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. +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. :::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. +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. ::: diff --git a/website/docs/add-secure-apps/providers/proxy/index.md b/website/docs/add-secure-apps/providers/proxy/index.md index 10c7d7deef..5c80a01727 100644 --- a/website/docs/add-secure-apps/providers/proxy/index.md +++ b/website/docs/add-secure-apps/providers/proxy/index.md @@ -1,7 +1,16 @@ --- -title: Proxy Provider +title: Proxy provider --- +The proxy provider protects applications that do not support native authentication protocols such as OIDC, SAML, or LDAP. + +Depending on the selected mode, one of the following happens: + +1. The authentik outpost proxies requests to the upstream application. +2. Your existing reverse proxy handles the application traffic and asks the authentik outpost to check authentication and authorization. + +Refer to the [create a proxy provider](./create-proxy-provider.md) documentation for setup instructions. + ```mermaid sequenceDiagram participant u as User accesses service @@ -20,92 +29,57 @@ sequenceDiagram end ``` -## Headers +## Proxy modes + +The proxy provider supports the following modes: + +| Mode | Use when | +| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | +| Proxy | The authentik outpost should proxy traffic to one upstream application. | +| Forward auth (single application) | Your existing reverse proxy should proxy traffic to one application and use authentik only for authentication checks. | +| Forward auth (domain level) | Your existing reverse proxy should use one proxy provider to protect multiple applications under the same parent domain. | + +Domain-level forward auth cannot enforce different application-level authorization rules for each protected application. Use single-application mode when each application needs its own policies, bindings, or authorization behavior. + +## Headers sent to upstream applications The proxy outpost sets the following user-specific headers: -### `X-authentik-username` +| Header | Example value | Description | +| -------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ | +| `X-authentik-username` | `akadmin` | Username of the currently logged in user. | +| `X-authentik-groups` | `foo\|bar\|baz` | Groups the user is a member of, separated by pipes. | +| `X-authentik-entitlements` | `foo\|bar\|baz` | Entitlements the user has for the application, separated by pipes. | +| `X-authentik-email` | `root@localhost` | Email address of the currently logged in user. | +| `X-authentik-name` | `authentik Default Admin` | Full name of the currently logged in user. | +| `X-authentik-uid` | `900347b8a29876b45ca6f75722635ecfedf0e931c6022e3a29a8aa13fb5516fb` | Hashed identifier of the currently logged in user. | -Example value: `akadmin` +The proxy outpost also sets the following application-specific headers: -The username of the currently logged in user +| Header | Example value | Description | +| --------------------------- | ------------------------------ | --------------------------------------------------------- | +| `X-authentik-meta-outpost` | `authentik Embedded Outpost` | Name of the authentik outpost. | +| `X-authentik-meta-provider` | `test` | Name of the authentik provider. | +| `X-authentik-meta-app` | `test` | Slug of the authentik application. | +| `X-authentik-meta-version` | `goauthentik.io/outpost/1.2.3` | Version of the authentik outpost. | +| `X-Forwarded-Host` | `app.company` | Original host sent by the client. Only set in proxy mode. | -### `X-authentik-groups` - -Example value: `foo|bar|baz` - -The groups the user is member of, separated by a pipe - -### `X-authentik-entitlements` - -Example value: `foo|bar|baz` - -The entitlements on the application this user has access to, separated by a pipe - -### `X-authentik-email` - -Example value: `root@localhost` - -The email address of the currently logged in user - -### `X-authentik-name` - -Example value: `authentik Default Admin` - -Full name of the current user - -### `X-authentik-uid` - -Example value: `900347b8a29876b45ca6f75722635ecfedf0e931c6022e3a29a8aa13fb5516fb` - -The hashed identifier of the currently logged in user. - -Besides these user-specific headers, some application specific headers are also set: - -### `X-authentik-meta-outpost` - -Example value: `authentik Embedded Outpost` - -The authentik outpost's name. - -### `X-authentik-meta-provider` - -Example value: `test` - -The authentik provider's name. - -### `X-authentik-meta-app` - -Example value: `test` - -The authentik application's slug. - -### `X-authentik-meta-version` - -Example value: `goauthentik.io/outpost/1.2.3` - -The authentik outpost's version. - -### `X-Forwarded-Host` - -:::info -Only set in proxy mode -::: - -The original Host header sent by the client. This is set as the `Host` header is set to the host of the configured backend. +In proxy mode, `X-Forwarded-Host` preserves the original `Host` header sent by the client because the `Host` header is set to the configured upstream host. ### Additional headers -Additionally, you can set `additionalHeaders` attribute on groups or users to set additional headers: +You can set the `additionalHeaders` attribute on groups or users to send additional static headers: ```yaml additionalHeaders: X-test-header: test-value ``` +For dynamic headers, see the [custom headers](./custom_headers.md) documentation. + ## HTTPS -The outpost listens on both 9000 for HTTP and 9443 for HTTPS. +The outpost listens on port `9000` for HTTP and port `9443` for HTTPS. :::info If your upstream host is HTTPS, and you're not using forward auth, you need to access the outpost over HTTPS too. @@ -113,35 +87,36 @@ If your upstream host is HTTPS, and you're not using forward auth, you need to a ## Logging out -Login is done automatically when you visit the domain without a valid cookie. +Login is initiated automatically when you visit the protected application without a valid cookie. -When using single-application mode, navigate to `app.domain.tld/outpost.goauthentik.io/sign_out`. +To log out, navigate to `/outpost.goauthentik.io/sign_out` on the host that serves the outpost: -When using domain-level mode, navigate to `auth.domain.tld/outpost.goauthentik.io/sign_out`, where auth.domain.tld is the external host configured for the provider. +- In proxy mode and forward auth single-application mode, use the protected application host, for example `https://app.company/outpost.goauthentik.io/sign_out`. +- In forward auth domain-level mode, use the authentication URL configured for the provider, for example `https://auth.company/outpost.goauthentik.io/sign_out`. -To log out, navigate to `/outpost.goauthentik.io/sign_out`. - -Starting with authentik 2023.2, when logging out of a provider, all the users sessions within the respective outpost are invalidated. +Logging out of a provider invalidates all sessions for that user within the respective outpost. ## Allowing unauthenticated requests -To allow un-authenticated requests to certain paths/URLs, you can use the _Unauthenticated URLs_ / _Unauthenticated Paths_ field. +To allow unauthenticated requests to specific paths or URLs, use the **Unauthenticated Paths** or **Unauthenticated URLs** field on the proxy provider. -Each new line is interpreted as a regular expression, and is compiled and checked using the standard Golang regex parser. +Each new line is interpreted as a regular expression and is compiled and checked using the standard Golang regex parser. -The behavior of this field changes depending on which mode you're in. +The behavior of this field changes depending on the selected mode. ### Proxy and Forward auth (single application) -In this mode, the regular expressions are matched against the Request's Path. +In these modes, the regular expressions are matched against the request path. ### Forward auth (domain level) -In this mode, the regular expressions are matched against the Request's full URL. +In this mode, the regular expressions are matched against the full request URL, including the scheme and host. ## Dynamic backend selection -You can configure the backend the proxy should access dynamically via scope mappings. To do this, create a scope mapping with a name and scope of your choice, and set the expression to: +In proxy mode, you can configure the upstream backend dynamically with scope mappings. + +Create a scope mapping with a name and scope of your choice, and set the expression to: ```python return { @@ -151,11 +126,13 @@ return { } ``` -Afterwards, edit the proxy provider and add this new mapping. The expression is only evaluated when the user logs into the application. +Edit the proxy provider and add this mapping under **Additional scopes**. The expression is evaluated only when the user logs in to the application. ## Host header:ak-version[2025.6.1] -By default, the proxy provider will use the forwarded host header received from the client. Starting with authentik 2025.6.1, it is possible to dynamically adjust the host header with a property mapping. To do this, create a scope mapping with a name and scope of your choice, and set the expression to: +By default, the proxy provider uses the forwarded host header received from the client. Starting with authentik 2025.6.1, you can dynamically adjust the host header with a property mapping. + +Create a scope mapping with a name and scope of your choice, and set the expression to: ```python return { @@ -165,7 +142,7 @@ return { } ``` -Afterwards, edit the proxy provider and add this new mapping. The expression is only evaluated when the user logs into the application. +Edit the proxy provider and add this mapping under **Additional scopes**. The expression is evaluated only when the user logs in to the application. ### Dynamically setting host header @@ -181,12 +158,12 @@ return { } ``` -Afterwards, edit the proxy provider and add this new mapping. The expression is only evaluated when the user logs into the application. +Edit the proxy provider and add this mapping under **Additional scopes**. The expression is evaluated only when the user logs in to the application. ## Proxy authentication -When a user authenticates to the proxy, authentik uses the OAuth client credentials grant as described in the [Header authentication](./header_authentication.mdx) and [Machine-to-Machine](../oauth2/machine_to_machine.mdx) documentation. +When a user authenticates to the proxy, authentik uses OAuth2 behavior configured on the proxy provider. For header-based authentication options, see [Header authentication](./header_authentication.mdx) and [Machine-to-Machine](../oauth2/machine_to_machine.mdx). ## Troubleshooting -To obtain more detailed information on a failure, you can search the logs of the server container. You will need to search for the `client_id` of the proxy provider that you're experiencing issues with. The `client_id` of a proxy provider can be obtained from its **Authentication** tab. +To obtain more detailed information about a failure, search the logs of the outpost or server container for the `client_id` of the proxy provider. The `client_id` is shown on the provider's **Authentication** tab. diff --git a/website/docs/add-secure-apps/providers/proxy/server_caddy.mdx b/website/docs/add-secure-apps/providers/proxy/server_caddy.mdx index 9c09669f13..007503478b 100644 --- a/website/docs/add-secure-apps/providers/proxy/server_caddy.mdx +++ b/website/docs/add-secure-apps/providers/proxy/server_caddy.mdx @@ -8,7 +8,7 @@ import Tabs from "@theme/Tabs"; import Placeholders from "./__placeholders.md"; import CaddyStandalone from "./_caddy_standalone.md"; -The configuration template shown below apply to both single-application and domain-level forward auth. +The configuration template shown below applies to both single-application and domain-level forward auth. diff --git a/website/docs/add-secure-apps/providers/proxy/server_envoy.mdx b/website/docs/add-secure-apps/providers/proxy/server_envoy.mdx index 0183f1e8ad..4b56cc3f40 100644 --- a/website/docs/add-secure-apps/providers/proxy/server_envoy.mdx +++ b/website/docs/add-secure-apps/providers/proxy/server_envoy.mdx @@ -8,7 +8,7 @@ import Tabs from "@theme/Tabs"; import Placeholders from "./__placeholders.md"; import EnvoyIstio from "./_envoy_istio.md"; -The configuration template shown below apply to both single-application and domain-level forward auth. +The configuration template shown below applies to both single-application and domain-level forward auth. :::info If you are using Istio and Kubernetes, use the port number that is exposed for your cluster. diff --git a/website/docs/sidebar.mjs b/website/docs/sidebar.mjs index 8d0d3cf608..8ee5468744 100644 --- a/website/docs/sidebar.mjs +++ b/website/docs/sidebar.mjs @@ -209,6 +209,7 @@ const items = [ id: "add-secure-apps/providers/proxy/index", }, items: [ + "add-secure-apps/providers/proxy/create-proxy-provider", "add-secure-apps/providers/proxy/custom_headers", "add-secure-apps/providers/proxy/header_authentication", {