mirror of
https://github.com/goauthentik/authentik.git
synced 2026-08-30 18:51:39 -07:00
@@ -144,9 +144,9 @@ Authoritative contributor docs live under `website/docs/developer-docs/` and are
|
||||
|
||||
- `setup/full-dev-environment.mdx` — full backend + frontend dev environment.
|
||||
- `setup/frontend-dev-environment.mdx` — web-only setup.
|
||||
- `setup/debugging.md` — attaching a debugger (VS Code config included).
|
||||
- `setup/debugging.mdx` — attaching a debugger (VS Code config included).
|
||||
- `docs/style-guide.mdx` — the canonical prose style guide (also governs this repo's docs).
|
||||
- `contributing.md` / top-level `CONTRIBUTING.md` — contribution process. `SECURITY.md` — reporting vulnerabilities.
|
||||
- `contributing.mdx` / top-level `CONTRIBUTING.md` — contribution process. `SECURITY.md` — reporting vulnerabilities.
|
||||
|
||||
## Tech stack
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ from authentik.policies.models import Policy, PolicyBindingModel
|
||||
from authentik.rbac.models import Role
|
||||
|
||||
# Context set when the serializer is created in a blueprint context
|
||||
# Update website/docs/customize/blueprints/v1/models.md when used
|
||||
# Update website/docs/customize/blueprints/v1/models.mdx when used
|
||||
SERIALIZER_CONTEXT_BLUEPRINT = "blueprint_entry"
|
||||
|
||||
|
||||
|
||||
@@ -63,8 +63,8 @@ class BaseEvaluator:
|
||||
|
||||
def __init__(self, filename: str | None = None):
|
||||
self._filename = filename if filename else "BaseEvaluator"
|
||||
# update website/docs/expressions/_objects.md
|
||||
# update website/docs/expressions/_functions.md
|
||||
# update website/docs/expressions/reference/_objects.mdx
|
||||
# update website/docs/expressions/reference/_functions.mdx
|
||||
self._globals = {
|
||||
"ak_call_policy": self.expr_func_call_policy,
|
||||
"ak_create_event": self.expr_event_create,
|
||||
|
||||
@@ -53,7 +53,7 @@ class ServiceConnectionInvalid(SentryIgnoredException):
|
||||
class OutpostConfig:
|
||||
"""Configuration an outpost uses to configure it self"""
|
||||
|
||||
# update website/docs/add-secure-apps/outposts/_config.md
|
||||
# update website/docs/add-secure-apps/outposts/_config.mdx
|
||||
|
||||
authentik_host: str = ""
|
||||
authentik_host_insecure: bool = False
|
||||
|
||||
@@ -28,8 +28,8 @@ class PolicyEvaluator(BaseEvaluator):
|
||||
def __init__(self, policy_name: str | None = None):
|
||||
super().__init__(policy_name or "PolicyEvaluator")
|
||||
self._messages = []
|
||||
# update website/docs/expressions/_objects.md
|
||||
# update website/docs/expressions/_functions.md
|
||||
# update website/docs/expressions/reference/_objects.mdx
|
||||
# update website/docs/expressions/reference/_functions.mdx
|
||||
self._context["ak_message"] = self.expr_func_message
|
||||
self._context["ak_user_has_authenticator"] = self.expr_func_user_has_authenticator
|
||||
|
||||
@@ -39,8 +39,8 @@ class PolicyEvaluator(BaseEvaluator):
|
||||
|
||||
def set_policy_request(self, request: PolicyRequest):
|
||||
"""Update context based on policy request (if http request is given, update that too)"""
|
||||
# update website/docs/expressions/_objects.md
|
||||
# update website/docs/expressions/_functions.md
|
||||
# update website/docs/expressions/reference/_objects.mdx
|
||||
# update website/docs/expressions/reference/_functions.mdx
|
||||
self._context["ak_is_sso_flow"] = request.context.get(PLAN_CONTEXT_SSO, False)
|
||||
if request.http_request:
|
||||
self.set_http_request(request.http_request)
|
||||
@@ -53,8 +53,8 @@ class PolicyEvaluator(BaseEvaluator):
|
||||
|
||||
def set_http_request(self, request: HttpRequest):
|
||||
"""Update context based on http request"""
|
||||
# update website/docs/expressions/_objects.md
|
||||
# update website/docs/expressions/_functions.md
|
||||
# update website/docs/expressions/reference/_objects.mdx
|
||||
# update website/docs/expressions/reference/_functions.mdx
|
||||
self._context["ak_client_ip"] = ip_address(ClientIPMiddleware.get_client_ip(request))
|
||||
self._context["http_request"] = request
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ LOGGER = get_logger()
|
||||
class FieldTypes(models.TextChoices):
|
||||
"""Field types an Prompt can be"""
|
||||
|
||||
# update website/docs/add-secure-apps/flows-stages/stages/prompt/index.md
|
||||
# update website/docs/add-secure-apps/flows-stages/stages/prompt/index.mdx
|
||||
|
||||
# Simple text field
|
||||
TEXT = "text", _("Text: Simple Text input")
|
||||
|
||||
@@ -24,7 +24,7 @@ import { AKApplicationWizard } from "#admin/applications/wizard/ak-application-w
|
||||
|
||||
import { Application, CoreApi, PoliciesApi } from "@goauthentik/api";
|
||||
|
||||
import MDApplication from "~docs/add-secure-apps/applications/index.md";
|
||||
import MDApplication from "~docs/add-secure-apps/applications/index.mdx";
|
||||
|
||||
import { msg, str } from "@lit/localize";
|
||||
import { css, CSSResult, html, nothing, PropertyValues, TemplateResult } from "lit";
|
||||
|
||||
@@ -20,13 +20,13 @@ import { SlottedTemplateResult } from "#elements/types";
|
||||
|
||||
import { ModelEnum, ProvidersApi, ProxyMode, ProxyProvider } from "@goauthentik/api";
|
||||
|
||||
import MDCaddyStandalone from "~docs/add-secure-apps/providers/proxy/_caddy_standalone.md";
|
||||
import MDNginxIngress from "~docs/add-secure-apps/providers/proxy/_nginx_ingress.md";
|
||||
import MDNginxPM from "~docs/add-secure-apps/providers/proxy/_nginx_proxy_manager.md";
|
||||
import MDNginxStandalone from "~docs/add-secure-apps/providers/proxy/_nginx_standalone.md";
|
||||
import MDTraefikCompose from "~docs/add-secure-apps/providers/proxy/_traefik_compose.md";
|
||||
import MDTraefikIngress from "~docs/add-secure-apps/providers/proxy/_traefik_ingress.md";
|
||||
import MDTraefikStandalone from "~docs/add-secure-apps/providers/proxy/_traefik_standalone.md";
|
||||
import MDCaddyStandalone from "~docs/add-secure-apps/providers/proxy/_caddy_standalone.mdx";
|
||||
import MDNginxIngress from "~docs/add-secure-apps/providers/proxy/_nginx_ingress.mdx";
|
||||
import MDNginxPM from "~docs/add-secure-apps/providers/proxy/_nginx_proxy_manager.mdx";
|
||||
import MDNginxStandalone from "~docs/add-secure-apps/providers/proxy/_nginx_standalone.mdx";
|
||||
import MDTraefikCompose from "~docs/add-secure-apps/providers/proxy/_traefik_compose.mdx";
|
||||
import MDTraefikIngress from "~docs/add-secure-apps/providers/proxy/_traefik_ingress.mdx";
|
||||
import MDTraefikStandalone from "~docs/add-secure-apps/providers/proxy/_traefik_standalone.mdx";
|
||||
import MDHeaderAuthentication from "~docs/add-secure-apps/providers/proxy/header_authentication.mdx";
|
||||
|
||||
import { msg } from "@lit/localize";
|
||||
|
||||
@@ -34,7 +34,7 @@ import {
|
||||
SCIMProvider,
|
||||
} from "@goauthentik/api";
|
||||
|
||||
import MDSCIMProvider from "~docs/add-secure-apps/providers/scim/index.md";
|
||||
import MDSCIMProvider from "~docs/add-secure-apps/providers/scim/index.mdx";
|
||||
|
||||
import { msg } from "@lit/localize";
|
||||
import { CSSResult, html, nothing, PropertyValues } from "lit";
|
||||
|
||||
@@ -24,7 +24,7 @@ import { scheduleCard } from "#components/tasks/scheduleCard";
|
||||
|
||||
import { KerberosSource, ModelEnum, SourcesApi } from "@goauthentik/api";
|
||||
|
||||
import MDSourceKerberosBrowser from "~docs/users-sources/sources/protocols/kerberos/browser.md";
|
||||
import MDSourceKerberosBrowser from "~docs/users-sources/sources/protocols/kerberos/browser.mdx";
|
||||
|
||||
import { msg } from "@lit/localize";
|
||||
import { CSSResult, html, nothing } from "lit";
|
||||
|
||||
10
web/types/mdx.d.ts
vendored
10
web/types/mdx.d.ts
vendored
@@ -1,18 +1,10 @@
|
||||
/**
|
||||
* @file Provides types for ESBuild "virtual modules" generated from
|
||||
* Markdown / MDX files. The bundler's `mdx-plugin` compiles these to
|
||||
* MDX files. The bundler's `mdx-plugin` compiles these to
|
||||
* HTML at build time and emits a JSON envelope; importing the file
|
||||
* yields the URL of that JSON envelope.
|
||||
*/
|
||||
|
||||
declare module "~docs/*.md" {
|
||||
/**
|
||||
* URL of the JSON envelope emitted for the imported file.
|
||||
*/
|
||||
const url: string;
|
||||
export default url;
|
||||
}
|
||||
|
||||
declare module "~docs/*.mdx" {
|
||||
/**
|
||||
* URL of the JSON envelope emitted for the imported file.
|
||||
|
||||
@@ -10,7 +10,7 @@ A shared `docusaurus-theme/` workspace package (`@goauthentik/docusaurus-theme`)
|
||||
|
||||
Theme customizations live in `docusaurus-theme/theme/` as **swizzled** components — Docusaurus's mechanism for overriding a built-in theme component by shadowing it at the same import path (e.g. `theme/EditThisPage`, `theme/DocItem/Content`, `theme/NotFound`). Most are _wrappers_ (render the original and add to it); a few are _ejected_ (full replacements). Because these override theme internals, they can break on a Docusaurus upgrade — prefer wrapping over ejecting, keep overrides minimal, and re-check them when bumping Docusaurus. Scaffold a new one with the `docusaurus swizzle` CLI (`npm run --prefix website/docs docusaurus -- swizzle @docusaurus/theme-classic <ComponentName> --wrap`; use `--eject` only when wrapping cannot express the change), then move the result into `docusaurus-theme/theme/` so all three sites share it.
|
||||
|
||||
You are most often editing **Markdown/MDX content**, not application code. Treat documentation as a product: every page has a URL that is a promise to readers, and prose must pass the linters and the spell checker.
|
||||
You are most often editing **MDX content**, not application code. Treat documentation as a product: every page has a URL that is a promise to readers, and prose must pass the linters and the spell checker.
|
||||
|
||||
## Commands
|
||||
|
||||
@@ -73,7 +73,7 @@ website/
|
||||
integrations/ # Integrations site (@goauthentik/integration-docs)
|
||||
<category>/<service>/index.mdx # one folder per service
|
||||
categories.mjs # Category list — drives the AUTO-GENERATED sidebar
|
||||
template/service.md # Template for a new integration guide
|
||||
template/service.mdx # Template for a new integration guide
|
||||
static/_redirects
|
||||
api/ # API site (@goauthentik/api-docs) — generated from ../schema.yml
|
||||
docusaurus-theme/ # Shared theme/components/redirect logic for all three sites
|
||||
@@ -85,10 +85,10 @@ website/
|
||||
|
||||
### Author-facing guides (source of truth — keep content consistent with these)
|
||||
|
||||
- `docs/developer-docs/docs/writing-documentation.md` — setup, build commands, glossary, page routing & redirects.
|
||||
- `docs/developer-docs/docs/writing-documentation.mdx` — setup, build commands, glossary, page routing & redirects.
|
||||
- `docs/developer-docs/docs/style-guide.mdx` — the canonical style guide (terminology, voice, formatting, accessibility, metadata).
|
||||
- `docs/developer-docs/docs/templates/` — `combo` / `procedural` / `conceptual` / `reference` templates (`*.tmpl.md`). Start from a template; default to **combo** unless the steps get buried, then split into procedural + conceptual.
|
||||
- `docs/developer-docs/contributing.md` — general contribution guidelines.
|
||||
- `docs/developer-docs/docs/templates/` — `combo` / `procedural` / `conceptual` / `reference` templates (`*.tmpl.mdx`). Start from a template; default to **combo** unless the steps get buried, then split into procedural + conceptual.
|
||||
- `docs/developer-docs/contributing.mdx` — general contribution guidelines.
|
||||
|
||||
When you change a documented workflow (commands, structure, conventions), update both this file **and** the corresponding author-facing guide so they don't drift.
|
||||
|
||||
@@ -100,20 +100,20 @@ The one rule the linters and spell checker cannot enforce, and the one most ofte
|
||||
|
||||
### Adding a Topics page
|
||||
|
||||
1. Create the `.md`/`.mdx` file under the appropriate `docs/<area>/` directory.
|
||||
1. Create the `.mdx` file under the appropriate `docs/<area>/` directory.
|
||||
2. **Add it to `docs/sidebar.mjs`** — otherwise it won't appear in the navigation.
|
||||
3. Run `make docs` before pushing.
|
||||
|
||||
### Adding an integration guide
|
||||
|
||||
1. Copy `integrations/template/service.md` into `integrations/<category>/<service>/index.mdx`. Pick a `<category>` from `integrations/categories.mjs`.
|
||||
1. Copy `integrations/template/service.mdx` into `integrations/<category>/<service>/index.mdx`. Pick a `<category>` from `integrations/categories.mjs`.
|
||||
2. Use placeholder domains `authentik.company` and `<app-name>.company` (drop the service domain for SaaS).
|
||||
3. **Do not edit the integrations sidebar** — it is auto-generated from `categories.mjs`.
|
||||
4. Run `make integrations` before pushing.
|
||||
|
||||
### Adding a glossary term
|
||||
|
||||
Create `docs/core/glossary/terms/<term>.mdx` with `sidebar_custom_props` frontmatter (`termName`, `tags`, optional `authentikSpecific`, `shortDescription`, optional `longDescription`). See `writing-documentation.md` for the field reference.
|
||||
Create `docs/core/glossary/terms/<term>.mdx` with `sidebar_custom_props` frontmatter (`termName`, `tags`, optional `authentikSpecific`, `shortDescription`, optional `longDescription`). See `writing-documentation.mdx` for the field reference.
|
||||
|
||||
## URLs and redirects
|
||||
|
||||
@@ -155,7 +155,7 @@ Every PR gets a Netlify Deploy Preview — use it to verify rendering, links, an
|
||||
| Concern | Tooling |
|
||||
| -------------- | ----------------------------------------------------------------------------------- |
|
||||
| Site generator | Docusaurus 3.x (classic preset + Mermaid) |
|
||||
| Content | Markdown / MDX + React |
|
||||
| Content | MDX + React |
|
||||
| API reference | `docusaurus-plugin-openapi-docs` (from schema) |
|
||||
| Build runtime | Node ≥ 24, npm ≥ 11 (run via `corepack`) |
|
||||
| Package layout | NPM Workspaces (`docs`, `integrations`, `api`, `docusaurus-theme`) |
|
||||
|
||||
@@ -24,13 +24,13 @@ Access requests provide:
|
||||
|
||||
## Terminology
|
||||
|
||||
| Term | Description |
|
||||
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Access request | A request from a specific user for access to an application. A request can be pending, approved, or denied. |
|
||||
| Request rule | A configuration that determines which request flow is used, who reviews requests, and how reviewers are notified. If no request flow is set on the request rule, it falls back to the request flow value set on the [brand](../../customize/branding/index.md). |
|
||||
| Request rule binding | A binding between a request rule and a requestable application. It also determines which users or groups can request access. |
|
||||
| Reviewer | A user or group authorized to approve or deny an access request. |
|
||||
| Expiry | The period for which access granted through an approved request remains valid. |
|
||||
| Term | Description |
|
||||
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Access request | A request from a specific user for access to an application. A request can be pending, approved, or denied. |
|
||||
| Request rule | A configuration that determines which request flow is used, who reviews requests, and how reviewers are notified. If no request flow is set on the request rule, it falls back to the request flow value set on the [brand](../../customize/branding/index.mdx). |
|
||||
| Request rule binding | A binding between a request rule and a requestable application. It also determines which users or groups can request access. |
|
||||
| Reviewer | A user or group authorized to approve or deny an access request. |
|
||||
| Expiry | The period for which access granted through an approved request remains valid. |
|
||||
|
||||
## Access request lifecycle
|
||||
|
||||
@@ -55,7 +55,7 @@ Submitting a request executes a request flow. Use this to collect a justificatio
|
||||
Configure a **Request flow** on either:
|
||||
|
||||
- The request rule itself.
|
||||
- As a default for the [brand](../../customize/branding/index.md). Used as a fallback when the request rule does not specify a request flow.
|
||||
- As a default for the [brand](../../customize/branding/index.mdx). Used as a fallback when the request rule does not specify a request flow.
|
||||
|
||||
authentik includes a `default-request` flow that is empty. This flow can be configured with any required stages and policies. Any prompt data entered by a requester during a request flow is shown to the reviewer in the **Requester notes** field. Request flows can be left empty if you don't require user interaction.
|
||||
|
||||
@@ -73,7 +73,7 @@ authentik includes a `default-request` flow that is empty. This flow can be conf
|
||||
- **Everyone who can approve**
|
||||
- **Only individually-selected reviewers**
|
||||
- **A random subset (of size “minimum reviewers”) of everyone who can approve**
|
||||
- **Notification transports** _(optional)_: The [notification transports](../../sys-mgmt/events/transports.md) used to notify reviewers.
|
||||
- **Notification transports** _(optional)_: The [notification transports](../../sys-mgmt/events/transports.mdx) used to notify reviewers.
|
||||
- **Request flow** _(optional)_: The [request flow](#request-flows) presented to the user when requesting access.
|
||||
4. Click **Create Request Rule**.
|
||||
|
||||
@@ -146,7 +146,7 @@ Each stage of a request is recorded as an event and can be matched in event matc
|
||||
- `access_request_denied`
|
||||
- `access_request_revoked`
|
||||
|
||||
Pair an event matcher policy with a notification rule to alert security teams of access events via Slack, email, or webhooks. See [Events](../../sys-mgmt/events/index.md) and [Notifications](../../sys-mgmt/events/notifications.md) for more information.
|
||||
Pair an event matcher policy with a notification rule to alert security teams of access events via Slack, email, or webhooks. See [Events](../../sys-mgmt/events/index.mdx) and [Notifications](../../sys-mgmt/events/notifications.mdx) for more information.
|
||||
|
||||
## Considerations and limitations
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ When a user logs into authentik, they see a list of the applications for which a
|
||||
|
||||
Applications are the "other half" of providers. They typically exist in a 1-to-1 relationship; each application needs a provider and every provider can be used with one application. Applications can, however, use specific, additional providers to augment the functionality of the main provider. For more information, see [Backchannel providers](./manage_apps.mdx#backchannel-providers).
|
||||
|
||||
Furthermore, the [RAC (Remote Access Control)](../providers/rac/index.md) feature uses a single application and a single provider, but multiple "endpoints". An endpoint defines each remote machine.
|
||||
Furthermore, the [RAC (Remote Access Control)](../providers/rac/index.mdx) feature uses a single application and a single provider, but multiple "endpoints". An endpoint defines each remote machine.
|
||||
|
||||
:::info
|
||||
For information about creating and managing applications, refer to [Manage applications](./manage_apps.mdx).
|
||||
@@ -33,7 +33,7 @@ The following options can be configured:
|
||||
|
||||
Only apps with launch URLs that begin with `http://` or `https://`, or that use relative paths, appear on the user's **Application Dashboard** page. To keep an app accessible but remove it from that page, use the **Hide from Application Dashboard** option (see [Hide applications](./manage_apps.mdx#hide-applications)).
|
||||
|
||||
- _Icon (URL)_: Optionally configure an icon for the application. You can select from files uploaded to the [Files](../../customize/files.md) library or enter an absolute URL.
|
||||
- _Icon (URL)_: Optionally configure an icon for the application. You can select from files uploaded to the [Files](../../customize/files.mdx) library or enter an absolute URL.
|
||||
|
||||
- _Publisher_: Text shown in the application card's expandable kebab menu (⋮)
|
||||
- _Description_: Text shown in the application card's expandable kebab menu (⋮)
|
||||
@@ -27,7 +27,7 @@ By default, if you click **New Application**, you are prompted to create the new
|
||||
|
||||
- **Configure the Provider**: provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and any additional required configurations.
|
||||
|
||||
- **Configure Bindings**: optionally create a [binding](../bindings-overview/index.md) between the application and a policy, group, or user. Application bindings control whether users can view and access the application from their **Application Dashboard** page. If you do not define any bindings, all users have access to the application. For more information, see [policy-driven authorization](#policy-driven-authorization), [application entitlements](#application-entitlements), and [hiding an application](#hide-applications).
|
||||
- **Configure Bindings**: optionally create a [binding](../bindings-overview/index.mdx) between the application and a policy, group, or user. Application bindings control whether users can view and access the application from their **Application Dashboard** page. If you do not define any bindings, all users have access to the application. For more information, see [policy-driven authorization](#policy-driven-authorization), [application entitlements](#application-entitlements), and [hiding an application](#hide-applications).
|
||||
|
||||
4. On the **Review and Submit Application** panel, review the configuration for the new application and its provider, and then click **Create Application**.
|
||||
|
||||
@@ -44,12 +44,12 @@ When multiple policies, groups, or users are attached, use **Policy engine mode*
|
||||
|
||||
The most common ways to control access to an application by using bindings are:
|
||||
|
||||
1. [Create a policy binding](../../customize/policies/working_with_policies.md#bind-a-policy-to-an-application) that determines whether a user can access an application.
|
||||
1. [Create a policy binding](../../customize/policies/working_with_policies.mdx#bind-a-policy-to-an-application) that determines whether a user can access an application.
|
||||
2. [Bind a user or group to the application](#bind-a-user-or-group-to-an-application).
|
||||
|
||||
### Policy-driven authorization
|
||||
|
||||
To use a [policy](../../customize/policies/index.md) to control which users or groups can access an application, click an application in the applications list, open the **Policy / Group / User Bindings** tab, and click **Create or bind...**. You can then create a new policy and bind it to the application, or select **Bind an existing policy** under **Bind Existing...**.
|
||||
To use a [policy](../../customize/policies/index.mdx) to control which users or groups can access an application, click an application in the applications list, open the **Policy / Group / User Bindings** tab, and click **Create or bind...**. You can then create a new policy and bind it to the application, or select **Bind an existing policy** under **Bind Existing...**.
|
||||
|
||||
### Bind a user or group to an application
|
||||
|
||||
@@ -125,7 +125,7 @@ To give users direct links to applications, you can now use a URL like `https://
|
||||
|
||||
## Backchannel providers
|
||||
|
||||
Backchannel providers can augment the functionality of applications by using additional protocols. The main provider of an application provides the SSO protocol that is used for logging into the application. Then, additional backchannel providers can be used for protocols such as [SCIM](../providers/scim/index.md) and [LDAP](../providers/ldap/index.md) to provide directory syncing.
|
||||
Backchannel providers can augment the functionality of applications by using additional protocols. The main provider of an application provides the SSO protocol that is used for logging into the application. Then, additional backchannel providers can be used for protocols such as [SCIM](../providers/scim/index.mdx) and [LDAP](../providers/ldap/index.mdx) to provide directory syncing.
|
||||
|
||||
Note that any access restrictions that are configured on an application apply to all of its backchannel providers.
|
||||
|
||||
@@ -134,7 +134,7 @@ To create a backchannel provider and then add it to an existing application, fol
|
||||
1. Log in to authentik as an administrator and open the authentik Admin interface.
|
||||
2. Navigate to **Applications** > **Providers** and click **Create**.
|
||||
|
||||
- **Choose a Provider Type**: The protocol for a backchannel provider must be [SCIM](../providers/scim/index.md), [LDAP](../providers/ldap/index.md), [Google Workspace (GWS)](../providers/gws/index.md), [Microsoft Entra ID](../providers/entra/index.md), or [Shared Signals Framework (SSF)](../providers/ssf/index.md).
|
||||
- **Choose a Provider Type**: The protocol for a backchannel provider must be [SCIM](../providers/scim/index.mdx), [LDAP](../providers/ldap/index.mdx), [Google Workspace (GWS)](../providers/gws/index.mdx), [Microsoft Entra ID](../providers/entra/index.mdx), or [Shared Signals Framework (SSF)](../providers/ssf/index.mdx).
|
||||
- **Configure the Provider**: Enter any required configurations.
|
||||
|
||||
3. Click **Finish** to save the provider.
|
||||
|
||||
@@ -6,12 +6,12 @@ sidebar_label: "Bindings"
|
||||
|
||||
A binding connects one authentik object to another object that uses it. Bindings let authentik answer two common questions:
|
||||
|
||||
- Where should authentik evaluate this [policy](../../customize/policies/index.md), user, or group?
|
||||
- Where should authentik insert this [stage](../flows-stages/stages/index.md) into a flow?
|
||||
- Where should authentik evaluate this [policy](../../customize/policies/index.mdx), user, or group?
|
||||
- Where should authentik insert this [stage](../flows-stages/stages/index.mdx) into a flow?
|
||||
|
||||
A policy answers "should this request pass?" A policy binding decides where authentik asks that question.
|
||||
|
||||
For a step-by-step guide, see [Work with bindings](./work-with-bindings.md).
|
||||
For a step-by-step guide, see [Work with bindings](./work-with-bindings.mdx).
|
||||
|
||||
## Binding types
|
||||
|
||||
@@ -132,7 +132,7 @@ If a target has no applicable bindings, authentik treats the result as passing.
|
||||
|
||||
A flow-stage binding attaches a stage to a flow and defines the order in which that stage runs. Flow-stage bindings are also called stage bindings.
|
||||
|
||||
authentik uses flow-stage bindings while building the [flow plan](../flows-stages/flow/planner.md). The flow plan determines which stages a user sees and in what order.
|
||||
authentik uses flow-stage bindings while building the [flow plan](../flows-stages/flow/planner.mdx). The flow plan determines which stages a user sees and in what order.
|
||||
|
||||
This matters because stages are reusable objects. The same stage can appear in multiple flows, but each flow-stage binding can have its own settings. When you bind a policy to a stage in a specific flow, you bind it to that flow-stage binding, not to the reusable stage definition itself.
|
||||
|
||||
@@ -143,7 +143,7 @@ Flow-stage bindings have two policy evaluation options:
|
||||
- **Evaluate when flow is planned**: authentik evaluates policies while building the flow plan.
|
||||
- **Evaluate when stage is run**: authentik evaluates policies immediately before presenting the stage.
|
||||
|
||||
At least one of these options must be enabled, and both can be enabled at the same time. For the full behavior and guidance on choosing the right setting, see [Flow Planner](../flows-stages/flow/planner.md#planning-and-stage-policies).
|
||||
At least one of these options must be enabled, and both can be enabled at the same time. For the full behavior and guidance on choosing the right setting, see [Flow Planner](../flows-stages/flow/planner.mdx#planning-and-stage-policies).
|
||||
|
||||
## What to remember
|
||||
|
||||
@@ -4,17 +4,17 @@ title: Work with bindings
|
||||
|
||||
Bindings are configured from the object that uses them. The exact page depends on what you want the binding to control.
|
||||
|
||||
For the concepts behind each binding type, see [Bindings in authentik](./index.md).
|
||||
For the concepts behind each binding type, see [Bindings in authentik](./index.mdx).
|
||||
|
||||
## Choose the right task
|
||||
|
||||
| Task | Start here | Use when |
|
||||
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
|
||||
| Add a stage to a flow | [Bind a stage to a flow](../flows-stages/stages/index.md#bind-a-stage-to-a-flow) | You want a flow to include a stage. |
|
||||
| Control whether a stage runs | [Bind users and groups to a flow's stage binding](../flows-stages/stages/index.md#bind-users-and-groups-to-a-flows-stage-binding) | You want a stage to run only for specific users or groups. |
|
||||
| Attach a policy to a target | [Bind a policy to a flow, stage binding, application, or source](../../customize/policies/working_with_policies.md#bind-a-policy-to-a-flow-stage-application-or-source) | You want a policy to decide whether a target passes. |
|
||||
| Control application access | [Use bindings to control access](../applications/manage_apps.mdx#use-bindings-to-control-access) | You want to limit who can view and launch an application. |
|
||||
| Control access inside an application | [Create an application entitlement](../applications/manage_apps.mdx#create-an-application-entitlement) | You want to grant access to a feature, role, or area inside an app. |
|
||||
| Task | Start here | Use when |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- |
|
||||
| Add a stage to a flow | [Bind a stage to a flow](../flows-stages/stages/index.mdx#bind-a-stage-to-a-flow) | You want a flow to include a stage. |
|
||||
| Control whether a stage runs | [Bind users and groups to a flow's stage binding](../flows-stages/stages/index.mdx#bind-users-and-groups-to-a-flows-stage-binding) | You want a stage to run only for specific users or groups. |
|
||||
| Attach a policy to a target | [Bind a policy to a flow, stage binding, application, or source](../../customize/policies/working_with_policies.mdx#bind-a-policy-to-a-flow-stage-application-or-source) | You want a policy to decide whether a target passes. |
|
||||
| Control application access | [Use bindings to control access](../applications/manage_apps.mdx#use-bindings-to-control-access) | You want to limit who can view and launch an application. |
|
||||
| Control access inside an application | [Create an application entitlement](../applications/manage_apps.mdx#create-an-application-entitlement) | You want to grant access to a feature, role, or area inside an app. |
|
||||
|
||||
## General workflow
|
||||
|
||||
@@ -34,4 +34,4 @@ Flow-stage bindings use the **Stage Bindings** tab on a flow. From that tab, you
|
||||
- If an application has no bindings, all users can access it.
|
||||
- If another policy binding target has no applicable bindings, authentik treats the result as passing.
|
||||
- User and group bindings require authentik to know the current user. In authentication and enrollment flows, bind user- or group-based checks to a flow-stage binding after the user is identified.
|
||||
- If a stage decision depends on data collected during the flow, enable **Evaluate when stage is run** on the flow-stage binding. For more information, see [Planning and stage policies](../flows-stages/flow/planner.md#planning-and-stage-policies).
|
||||
- If a stage decision depends on data collected during the flow, enable **Evaluate when stage is run** on the flow-stage binding. For more information, see [Planning and stage policies](../flows-stages/flow/planner.mdx#planning-and-stage-policies).
|
||||
@@ -13,7 +13,7 @@ For example, in the Identification Stage (part of the default login flow), you c
|
||||
|
||||
Any data can be stored in the flow context, however there are some reserved keys in the context dictionary that are used by authentik stages.
|
||||
|
||||
To manage flow context on a more granular level, see [Setting flow context keys](../../../../customize/policies/types/expression/managing_flow_context_keys.md).
|
||||
To manage flow context on a more granular level, see [Setting flow context keys](../../../../customize/policies/types/expression/managing_flow_context_keys.mdx).
|
||||
|
||||
## Context dictionary and reserved keys
|
||||
|
||||
@@ -29,13 +29,13 @@ Keys prefixed with `goauthentik.io` are used internally by authentik and are sub
|
||||
|
||||
#### `pending_user` ([User object](../../../../users-sources/user/user_ref.mdx#object-properties))
|
||||
|
||||
`pending_user` is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the [Identification stage](../../stages/identification/index.md).
|
||||
`pending_user` is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the [Identification stage](../../stages/identification/index.mdx).
|
||||
|
||||
Stages that require a user, such as the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md), and others will use this value if it is set, and fall back to the request's user when possible.
|
||||
Stages that require a user, such as the [Password stage](../../stages/password/index.mdx), the [Authenticator validation stage](../../stages/authenticator_validate/index.mdx), and others will use this value if it is set, and fall back to the request's user when possible.
|
||||
|
||||
#### `prompt_data` (Dictionary)
|
||||
|
||||
`prompt_data` is primarily used by the [Prompt stage](../../stages/prompt/index.md). The value of any field within a prompt stage is written to the `prompt_data` dictionary. For example, given a field with the _Field key_ `email` that was submitted with the value `foo@bar.baz` will result in the following context:
|
||||
`prompt_data` is primarily used by the [Prompt stage](../../stages/prompt/index.mdx). The value of any field within a prompt stage is written to the `prompt_data` dictionary. For example, given a field with the _Field key_ `email` that was submitted with the value `foo@bar.baz` will result in the following context:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -45,7 +45,7 @@ Stages that require a user, such as the [Password stage](../../stages/password/i
|
||||
}
|
||||
```
|
||||
|
||||
This data can be modified with policies. The data is also used by stages like [User write](../../stages/user_write/index.md), which takes data in `prompt_data` and writes it to `pending_user`.
|
||||
This data can be modified with policies. The data is also used by stages like [User write](../../stages/user_write/index.mdx), which takes data in `prompt_data` and writes it to `pending_user`.
|
||||
|
||||
#### `redirect` (string)
|
||||
|
||||
@@ -65,7 +65,7 @@ When a user authenticates/enrolls via an external source, this will be set to th
|
||||
|
||||
#### `outpost` (dictionary)
|
||||
|
||||
When a flow is executed by an Outpost (for example the [LDAP](../../../providers/ldap/index.md) or [RADIUS](../../../providers/radius/index.mdx)), this will be set to a dictionary containing the Outpost instance under the key `"instance"`.
|
||||
When a flow is executed by an Outpost (for example the [LDAP](../../../providers/ldap/index.mdx) or [RADIUS](../../../providers/radius/index.mdx)), this will be set to a dictionary containing the Outpost instance under the key `"instance"`.
|
||||
|
||||
### Scenario-specific keys
|
||||
|
||||
@@ -75,11 +75,11 @@ This key is set to `True` when the flow is executed from an "SSO" context. For e
|
||||
|
||||
#### `is_restored` (Token object)
|
||||
|
||||
This key is set when a flow execution is continued from a token. This happens for example when an [Email stage](../../stages/email/index.md) is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution. This field is also used by the [Source stage](../../stages/source/index.md) when returning back to the initial flow the Source stage was run on.
|
||||
This key is set when a flow execution is continued from a token. This happens for example when an [Email stage](../../stages/email/index.mdx) is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution. This field is also used by the [Source stage](../../stages/source/index.mdx) when returning back to the initial flow the Source stage was run on.
|
||||
|
||||
#### `is_redirected` (Flow object)
|
||||
|
||||
This key is set when the current flow was reached through a [Redirect stage](../../stages/redirect/index.md) in Flow mode.
|
||||
This key is set when the current flow was reached through a [Redirect stage](../../stages/redirect/index.mdx) in Flow mode.
|
||||
|
||||
### Stage-specific keys
|
||||
|
||||
@@ -149,11 +149,11 @@ Type the `pending_user` will be created as. Must be one of `internal`, `external
|
||||
|
||||
##### `user_backend` (string)
|
||||
|
||||
Set by the [Password stage](../../stages/password/index.md) after successfully authenticating the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.
|
||||
Set by the [Password stage](../../stages/password/index.mdx) after successfully authenticating the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.
|
||||
|
||||
##### `auth_method` (string)
|
||||
|
||||
Set by the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md), the [OAuth2 Provider](../../../providers/oauth2/index.mdx), and the API authentication depending on which method was used to authenticate.
|
||||
Set by the [Password stage](../../stages/password/index.mdx), the [Authenticator validation stage](../../stages/authenticator_validate/index.mdx), the [OAuth2 Provider](../../../providers/oauth2/index.mdx), and the API authentication depending on which method was used to authenticate.
|
||||
|
||||
Possible options:
|
||||
|
||||
@@ -163,7 +163,7 @@ Possible options:
|
||||
- `auth_mfa` (Authentication via MFA device without password)
|
||||
- `auth_webauthn_pwl` (Passwordless authentication via WebAuthn with Passkeys)
|
||||
- `jwt` ([M2M](../../../providers/oauth2/machine_to_machine.mdx) authentication via an existing JWT)
|
||||
- `mtls` (Authentication via Certificate, see [Mutual TLS Stage](../../stages/mtls/index.md))
|
||||
- `mtls` (Authentication via Certificate, see [Mutual TLS Stage](../../stages/mtls/index.mdx))
|
||||
|
||||
##### `auth_method_args` (dictionary)
|
||||
|
||||
@@ -227,7 +227,7 @@ This value can be set either via [Prompt data](#prompt_data-dictionary) or via p
|
||||
|
||||
##### `redirect_stage_target` (string)
|
||||
|
||||
[Set this key](../../../../customize/policies/types/expression/managing_flow_context_keys.md) in an Expression Policy to override [Redirect stage](../../stages/redirect/index.md) to force it to redirect to a certain URL or flow. This is useful when a flow requires that the redirection target be decided dynamically.
|
||||
[Set this key](../../../../customize/policies/types/expression/managing_flow_context_keys.mdx) in an Expression Policy to override [Redirect stage](../../stages/redirect/index.mdx) to force it to redirect to a certain URL or flow. This is useful when a flow requires that the redirection target be decided dynamically.
|
||||
|
||||
Use the format `ak-flow://{slug}` to use the Redirect stage in Flow mode. Any other format will result in the Redirect stage running in Static mode.
|
||||
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
title: Default flows
|
||||
---
|
||||
|
||||
When you create a new provider, you can select certain default flows that will be used with the provider and its associated application. For example, you can [create a flow](./index.md#create-a-flow) that overrides the defaults configured on the brand.
|
||||
|
||||
If no default flow is selected when the provider is created, authentik will first check if there is a default flow configured in the active [**Brand**](../../../customize/branding/index.md). If no default is configured there, authentik will go through all flows with the matching designation, sorted by `slug`, evaluate policies bound directly to the flows, and pick the first flow whose policies allow access.
|
||||
|
||||
import DefaultFlowList from "../flow/flow_list/\_defaultflowlist.mdx";
|
||||
|
||||
<DefaultFlowList />
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Default flows
|
||||
---
|
||||
|
||||
When you create a new provider, you can select certain default flows that will be used with the provider and its associated application. For example, you can [create a flow](./index.mdx#create-a-flow) that overrides the defaults configured on the brand.
|
||||
|
||||
If no default flow is selected when the provider is created, authentik will first check if there is a default flow configured in the active [**Brand**](../../../customize/branding/index.mdx). If no default is configured there, authentik will go through all flows with the matching designation, sorted by `slug`, evaluate policies bound directly to the flows, and pick the first flow whose policies allow access.
|
||||
|
||||
import DefaultFlowList from "../flow/flow_list/\_defaultflowlist.mdx";
|
||||
|
||||
<DefaultFlowList />
|
||||
@@ -50,7 +50,7 @@ Passwordless login flow that lets users sign in from a link sent to their email
|
||||
|
||||
Before importing this flow, make sure that global email settings are configured and that users have valid email addresses. Use this flow only when access to the user's email inbox is an acceptable sign-in factor for your environment.
|
||||
|
||||
After import, review the Email stage binding in the flow. The example uses the built-in account confirmation email template. You can replace it with a [custom email template](../../stages/email/index.md#custom-templates) if you want the email text to match the magic-link login experience.
|
||||
After import, review the Email stage binding in the flow. The example uses the built-in account confirmation email template. You can replace it with a [custom email template](../../stages/email/index.mdx#custom-templates) if you want the email text to match the magic-link login experience.
|
||||
|
||||
## Log in with conditional CAPTCHA
|
||||
|
||||
@@ -6,6 +6,6 @@ The headless flow executor is used by clients that don't have access to the web
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [**Identification stage**](../../stages/identification/index.md)
|
||||
- [**Password stage**](../../stages/password/index.md)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)
|
||||
- [**Identification stage**](../../stages/identification/index.mdx)
|
||||
- [**Password stage**](../../stages/password/index.mdx)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.mdx)
|
||||
@@ -11,16 +11,16 @@ Currently this flow executor is automatically used for the following browsers:
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [**Identification stage**](../../stages/identification/index.md)
|
||||
- [**Identification stage**](../../stages/identification/index.mdx)
|
||||
|
||||
:::info
|
||||
Only user identifier and user identifier + password stage configurations are supported; sources and passwordless configurations are not supported.
|
||||
:::
|
||||
|
||||
- [**Password stage**](../../stages/password/index.md)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)
|
||||
- [**Password stage**](../../stages/password/index.mdx)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.mdx)
|
||||
|
||||
Compared to the [default flow executor](./if-flow.md), this flow executor does _not_ support the following features:
|
||||
Compared to the [default flow executor](./if-flow.mdx), this flow executor does _not_ support the following features:
|
||||
|
||||
- Localization
|
||||
- Theming (Dark / light themes)
|
||||
@@ -6,4 +6,4 @@ The user interface (/if/user/) uses a specialized flow executor to allow individ
|
||||
|
||||
Because the stages in a flow can change during its execution, be aware that configuring this executor to use any stage type other than Prompt or User Write will automatically trigger a redirect to the standard executor.
|
||||
|
||||
An admin can customize which fields can be changed by the user by updating the default-user-settings-flow, or copying it to create a new flow with a Prompt Stage and a User Write Stage. Different variants of your flow can be applied to different [Brands](../../../../customize/branding/index.md) on the same authentik instance.
|
||||
An admin can customize which fields can be changed by the user by updating the default-user-settings-flow, or copying it to create a new flow with a Prompt Stage and a User Write Stage. Different variants of your flow can be applied to different [Brands](../../../../customize/branding/index.mdx) on the same authentik instance.
|
||||
@@ -1,18 +1,18 @@
|
||||
- **Authentication**: this option designates a flow to be used for authentication. The authentication flow should always contain a [**User Login**](../../stages/user_login/index.md) stage, which attaches the staged user to the current session.
|
||||
- **Authentication**: this option designates a flow to be used for authentication. The authentication flow should always contain a [**User Login**](../../stages/user_login/index.mdx) stage, which attaches the staged user to the current session.
|
||||
|
||||
- **Authorization**: designates a flow to be used for authorization of an application. Can be used to add additional verification steps before the user is allowed to access an application. This flow is defined per provider, when the provider is created, to state whether implicit or explicit authorization is required.
|
||||
|
||||
- **Enrollment**: designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**Email**](../../stages/email/index.md) or **Captcha**. At the end, to create the user, you can use the [**User Write**](../../stages/user_write/index.md) stage, which either updates the currently staged user, or if none exists, creates a new one.
|
||||
- **Enrollment**: designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**Email**](../../stages/email/index.mdx) or **Captcha**. At the end, to create the user, you can use the [**User Write**](../../stages/user_write/index.mdx) stage, which either updates the currently staged user, or if none exists, creates a new one.
|
||||
|
||||
- **Invalidation**: designates a default flow to be used to invalidate a session. There are two default invalidation flows:
|
||||
- `default-invalidation-flow`: Used when a user logs out directly from authentik. This flow **includes** a [**User Logout**](../../stages/user_logout/index.md) stage, which ends the authentik session and triggers [Single Logout](../../../providers/single-logout/index.md) for all connected applications.
|
||||
- `default-invalidation-flow`: Used when a user logs out directly from authentik. This flow **includes** a [**User Logout**](../../stages/user_logout/index.mdx) stage, which ends the authentik session and triggers [Single Logout](../../../providers/single-logout/index.mdx) for all connected applications.
|
||||
|
||||
- `default-provider-invalidation-flow`: Used when a user logs out from an application (OIDC, SAML, Proxy, or RAC providers). By default, this flow does **not** include a User Logout stage, meaning only the specific application session ends while the authentik session remains active. For instructions on how to also end the authentik session when a user logs out from an application, see the [Single Logout documentation](../../../providers/single-logout/index.md#enable-full-single-logout-for-rp-initiated-logout).
|
||||
- `default-provider-invalidation-flow`: Used when a user logs out from an application (OIDC, SAML, Proxy, or RAC providers). By default, this flow does **not** include a User Logout stage, meaning only the specific application session ends while the authentik session remains active. For instructions on how to also end the authentik session when a user logs out from an application, see the [Single Logout documentation](../../../providers/single-logout/index.mdx#enable-full-single-logout-for-rp-initiated-logout).
|
||||
|
||||
You can also create custom invalidation flows with branded background images or different logout options.
|
||||
|
||||
- **Recovery**: designates a flow for recovery. This flow normally contains an [**Identification**](../../stages/identification/index.md) stage to find the user. It can also contain any amount of verification stages, such as [**Email**](../../stages/email/index.md) or [**CAPTCHA**](../../stages/captcha/index.md). Afterwards, use the [**Prompt**](../../stages/prompt/index.md) stage to ask the user for a new password and the [**User Write**](../../stages/user_write/index.md) stage to update the password.
|
||||
- **Recovery**: designates a flow for recovery. This flow normally contains an [**Identification**](../../stages/identification/index.mdx) stage to find the user. It can also contain any amount of verification stages, such as [**Email**](../../stages/email/index.mdx) or [**CAPTCHA**](../../stages/captcha/index.mdx). Afterwards, use the [**Prompt**](../../stages/prompt/index.mdx) stage to ask the user for a new password and the [**User Write**](../../stages/user_write/index.mdx) stage to update the password.
|
||||
|
||||
- **Stage Configuration**: designates a flow for general setup. This designation doesn't impose any constraints on what you can do. For example, by default this designation is used to configure authenticators, like changing a password and setting up TOTP.
|
||||
|
||||
- **Unenrollment**: designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](../../stages/email/index.md) or [**Captcha**](../../stages/captcha/index.md). As a final stage, to delete the account, use the [**user_delete**](../../stages/user_delete/index.md) stage.
|
||||
- **Unenrollment**: designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](../../stages/email/index.mdx) or [**Captcha**](../../stages/captcha/index.mdx). As a final stage, to delete the account, use the [**user_delete**](../../stages/user_delete/index.mdx) stage.
|
||||
|
||||
@@ -3,9 +3,9 @@ title: Flows
|
||||
sidebar_label: "Flows"
|
||||
---
|
||||
|
||||
Flows are a major component in authentik. In conjunction with [stages](../stages/index.md) and [policies](../../../customize/policies/index.md), flows are at the heart of our system of building blocks, used to define and execute the workflows of authentication, authorization, enrollment, and user settings.
|
||||
Flows are a major component in authentik. In conjunction with [stages](../stages/index.mdx) and [policies](../../../customize/policies/index.mdx), flows are at the heart of our system of building blocks, used to define and execute the workflows of authentication, authorization, enrollment, and user settings.
|
||||
|
||||
There are over a dozen default, out-of-the-box flows available in authentik. Users can decide if they already have everything they need with the [default flows](../flow/default-flows.md) or if they want to [create](#create-a-flow) their own customized flow, using the Admin interface, Terraform, or via the API.
|
||||
There are over a dozen default, out-of-the-box flows available in authentik. Users can decide if they already have everything they need with the [default flows](../flow/default-flows.mdx) or if they want to [create](#create-a-flow) their own customized flow, using the Admin interface, Terraform, or via the API.
|
||||
|
||||
A flow is a method of describing a sequence of stages. A stage represents a single verification or logic step. By connecting a series of stages within a flow (and optionally attaching policies as needed) you can build a highly flexible process for authenticating users, enrolling them, and more.
|
||||
|
||||
@@ -21,11 +21,11 @@ When these stages are successfully completed, authentik logs in the user.
|
||||
|
||||
By default, policies bound to stage bindings are evaluated dynamically, right before the stage is presented to the user. This flexibility allows the login process to continue, change, or stop, based on the success or failure of each policy.
|
||||
|
||||
You can change this behavior by enabling the **Evaluate when flow is planned** option on the stage binding. When this option is enabled, authentik uses the [Flow Planner](./planner.md) to evaluate the stage binding's policies when the flow starts, and includes the stage in the flow plan only if those policies pass.
|
||||
You can change this behavior by enabling the **Evaluate when flow is planned** option on the stage binding. When this option is enabled, authentik uses the [Flow Planner](./planner.mdx) to evaluate the stage binding's policies when the flow starts, and includes the stage in the flow plan only if those policies pass.
|
||||
|
||||
## Policies and permissions
|
||||
|
||||
Flows can have [policies](../../../customize/policies/index.md) assigned to them. These policies determine if the current user is allowed to see and use this flow.
|
||||
Flows can have [policies](../../../customize/policies/index.mdx) assigned to them. These policies determine if the current user is allowed to see and use this flow.
|
||||
|
||||
Keep in mind that in certain circumstances, policies cannot match against users and groups as there is no authenticated user yet.
|
||||
|
||||
@@ -35,7 +35,7 @@ Flows can be imported and exported (as [blueprints](../../../customize/blueprint
|
||||
|
||||
Flows can be imported to add new functionality to existing flows, or to add a new custom flow.
|
||||
|
||||
You can download our [Example flows](./examples/flows.md) and then import them into your authentik instance, or create a new flow.
|
||||
You can download our [Example flows](./examples/flows.mdx) and then import them into your authentik instance, or create a new flow.
|
||||
|
||||
Starting with authentik 2022.8, flows are exported as YAML, but legacy JSON-based flows can still be imported.
|
||||
|
||||
@@ -53,9 +53,9 @@ To create a flow, follow these steps:
|
||||
2. In the Admin interface, navigate to **Flows and Stages > Flows**.
|
||||
3. Click **New Flow**, define the flow using the [configuration settings](#flow-configuration-options) described below, and then click **Create Flow**.
|
||||
|
||||
After creating the flow, you can then [bind specific stages](../stages/index.md#bind-a-stage-to-a-flow) to the flow and [bind policies](../../../customize/policies/bindings.md) to the flow to further customize the user's log in and authentication process.
|
||||
After creating the flow, you can then [bind specific stages](../stages/index.mdx#bind-a-stage-to-a-flow) to the flow and [bind policies](../../../customize/policies/bindings.mdx) to the flow to further customize the user's log in and authentication process.
|
||||
|
||||
To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/branding/index.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
|
||||
To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/branding/index.mdx). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
|
||||
|
||||
## Flow configuration options
|
||||
|
||||
@@ -75,7 +75,7 @@ import Defaultflowlist from "../flow/flow_list/\_defaultflowlist.mdx";
|
||||
|
||||
<Defaultflowlist />
|
||||
|
||||
**Authentication**: Using this option, you can configure whether the flow requires initial authentication or not, whether the user must be a superuser, if the flow can only be started after being redirected by a [Redirect stage](../stages/redirect/index.md), or if the flow requires an outpost.
|
||||
**Authentication**: Using this option, you can configure whether the flow requires initial authentication or not, whether the user must be a superuser, if the flow can only be started after being redirected by a [Redirect stage](../stages/redirect/index.mdx), or if the flow requires an outpost.
|
||||
|
||||
**Behavior settings**:
|
||||
|
||||
@@ -96,7 +96,7 @@ import Defaultflowlist from "../flow/flow_list/\_defaultflowlist.mdx";
|
||||
|
||||
- **Layout**: select how the UI displays the flow when it is executed; with stacked elements, content left or right, and sidebar left or right.
|
||||
|
||||
- **Background**: optionally, select a background image for the UI presentation of the flow. This overrides any default background image configured in the [Branding settings](../../../customize/branding/index.md#branding-settings). See [File picker values](../../../customize/file-picker.md).
|
||||
- **Background**: optionally, select a background image for the UI presentation of the flow. This overrides any default background image configured in the [Branding settings](../../../customize/branding/index.mdx#branding-settings). See [File picker values](../../../customize/file-picker.mdx).
|
||||
|
||||
## Edit or delete a flow
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Flow Inspector
|
||||
---
|
||||
|
||||
The Flow Inspector allows administrators to visually determine how custom flows work, inspect the current [flow context](./context/index.mdx) by stepping through the flow process and observing the Inspector with each step, and investigate issues. It shows details from the active [flow plan](./planner.md).
|
||||
The Flow Inspector allows administrators to visually determine how custom flows work, inspect the current [flow context](./context/index.mdx) by stepping through the flow process and observing the Inspector with each step, and investigate issues. It shows details from the active [flow plan](./planner.mdx).
|
||||
|
||||
As shown in the screenshot below, the Flow Inspector displays to the right, beside the selected flow (in this case, "Change Password"), with [information](#flow-inspector-details) about that specific flow and flow context.
|
||||
|
||||
@@ -11,10 +11,10 @@ As shown in the screenshot below, the Flow Inspector displays to the right, besi
|
||||
## Access the Flow Inspector
|
||||
|
||||
:::warning
|
||||
Be aware that when running a flow with the Inspector enabled, the flow is still executed normally. This means that, for example, a [User write](../stages/user_write/index.md) stage _will_ write user data.
|
||||
Be aware that when running a flow with the Inspector enabled, the flow is still executed normally. This means that, for example, a [User write](../stages/user_write/index.mdx) stage _will_ write user data.
|
||||
:::
|
||||
|
||||
The Inspector is accessible to users that have been granted the [permission](../../../users-sources/access-control/permissions.md) **Can inspect a Flow's execution**, either directly or through a role. Superusers can always inspect flow executions.
|
||||
The Inspector is accessible to users that have been granted the [permission](../../../users-sources/access-control/permissions.mdx) **Can inspect a Flow's execution**, either directly or through a role. Superusers can always inspect flow executions.
|
||||
|
||||
### Manually run a flow with the Inspector
|
||||
|
||||
@@ -30,13 +30,13 @@ The Inspector is accessible to users that have been granted the [permission](../
|
||||
|
||||
Alternatively, a user with the correct permission can launch the Inspector by adding the query parameter `?inspector` to the URL after the URL opens on a flow.
|
||||
|
||||
Users with permissions to access the Flow Inspector see a button in the top-right corner of the [default flow executor](./executors/if-flow.md) to open the Inspector.
|
||||
Users with permissions to access the Flow Inspector see a button in the top-right corner of the [default flow executor](./executors/if-flow.mdx) to open the Inspector.
|
||||
|
||||
When developing authentik with the debug mode enabled, the Inspector is enabled by default and can be accessed by both unauthenticated users and standard users. However, debug mode should only be used for the development of authentik. Unless you are a developer and need the more verbose error information, the best practice for using the Flow Inspector is to assign the permission, not use debug mode.
|
||||
|
||||
:::info Troubleshooting
|
||||
|
||||
- If the Flow Inspector does not launch and a "Bad request" error displays, this is likely either because you selected a flow that has a policy bound directly to it that prevents access (so the Inspector won't open because the flow can't be executed) or because you do not have [view permission](../../../users-sources/access-control/manage_permissions.md#view-permissions) on that specific flow.
|
||||
- If the Flow Inspector does not launch and a "Bad request" error displays, this is likely either because you selected a flow that has a policy bound directly to it that prevents access (so the Inspector won't open because the flow can't be executed) or because you do not have [view permission](../../../users-sources/access-control/manage_permissions.mdx#view-permissions) on that specific flow.
|
||||
:::
|
||||
|
||||
### Flow Inspector details
|
||||
@@ -45,7 +45,7 @@ The following information is shown in the Inspector:
|
||||
|
||||
#### Next stage
|
||||
|
||||
This is the currently planned next stage. Stages that are evaluated when they run can still be skipped before they are shown. For more information, see [Planning and stage policies](./planner.md#planning-and-stage-policies).
|
||||
This is the currently planned next stage. Stages that are evaluated when they run can still be skipped before they are shown. For more information, see [Planning and stage policies](./planner.mdx#planning-and-stage-policies).
|
||||
|
||||
The name and kind of the stage, as well as the unique ID, are shown.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Flow Planner
|
||||
---
|
||||
|
||||
The Flow Planner is the component of authentik that takes a configured [flow](./index.md) and, for each incoming request for that flow, determines the specific stages to run and the order in which they will run.
|
||||
The Flow Planner is the component of authentik that takes a configured [flow](./index.mdx) and, for each incoming request for that flow, determines the specific stages to run and the order in which they will run.
|
||||
|
||||
A flow describes a sequence of stages and policies. A flow plan is the per-session execution plan derived from that flow after authentik evaluates the request, the user, and the policies bound to the flow and its stage bindings.
|
||||
|
||||
@@ -16,7 +16,7 @@ When a flow is executed, authentik creates a flow plan and does the following:
|
||||
4. Evaluates stage binding policies when **Evaluate when flow is planned** is enabled.
|
||||
5. Stores the resulting ordered stage list and [flow context](./context/index.mdx) in the user's session.
|
||||
|
||||
The [flow executor](./executors/if-flow.md) then presents the first stage of the flow plan. When the stage completes successfully, authentik removes it from the flow plan and continues with the next stage. When no stages remain, the flow plan has completed.
|
||||
The [flow executor](./executors/if-flow.mdx) then presents the first stage of the flow plan. When the stage completes successfully, authentik removes it from the flow plan and continues with the next stage. When no stages remain, the flow plan has completed.
|
||||
|
||||
## Planning and stage policies
|
||||
|
||||
@@ -31,7 +31,7 @@ For example, a password stage usually depends on the user identified by an earli
|
||||
|
||||
## Inspect a plan
|
||||
|
||||
Use the [Flow Inspector](./inspector.md) to execute a flow and, while it executes, view the current stage, the next planned stage, the plan history, and the current plan context.
|
||||
Use the [Flow Inspector](./inspector.mdx) to execute a flow and, while it executes, view the current stage, the next planned stage, the plan history, and the current plan context.
|
||||
|
||||
The Flow Inspector is accessed via the Flow Overview page and is particularly useful for troubleshooting flows and determining why stage binding policies fail to pass. It's also useful to evaluate values for use in policies.
|
||||
|
||||
@@ -8,7 +8,7 @@ authentik_enterprise: true
|
||||
This stage performs destructive actions on a user account. Ensure the flow includes appropriate warnings and confirmation steps before this stage executes.
|
||||
:::
|
||||
|
||||
The Account Lockdown stage executes security lockdown actions on a target user account. For the feature overview and usage instructions, see [Account Lockdown](../../../../security/account-lockdown.md).
|
||||
The Account Lockdown stage executes security lockdown actions on a target user account. For the feature overview and usage instructions, see [Account Lockdown](../../../../security/account-lockdown.mdx).
|
||||
|
||||
## Stage behavior
|
||||
|
||||
@@ -61,7 +61,7 @@ The completion flow must have **Authentication** set to **No authentication requ
|
||||
|
||||
## Events
|
||||
|
||||
Creates a **User Write** event with an account-lockdown action ID. Use [Notification Rules](../../../../sys-mgmt/events/index.md) to send alerts. To match account-lockdown events, use action `user_write` and query `context.action_id = "account_lockdown"`.
|
||||
Creates a **User Write** event with an account-lockdown action ID. Use [Notification Rules](../../../../sys-mgmt/events/index.mdx) to send alerts. To match account-lockdown events, use action `user_write` and query `context.action_id = "account_lockdown"`.
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -6,7 +6,7 @@ The Duo Authenticator Setup stage enrolls a Duo authenticator for the current us
|
||||
|
||||
## About the Duo authenticator setup stage
|
||||
|
||||
This stage connects authentik to Duo and stores a Duo-backed authenticator for the user. Duo can then be used with the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
This stage connects authentik to Duo and stores a Duo-backed authenticator for the user. Duo can then be used with the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -22,7 +22,7 @@ This stage connects authentik to Duo and stores a Duo-backed authenticator for t
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user should enroll Duo.
|
||||
|
||||
To require Duo during authentication, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the login flow and allow the **Duo** device class.
|
||||
To require Duo during authentication, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the login flow and allow the **Duo** device class.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -9,7 +9,7 @@ The Email Authenticator Setup stage registers an email-based authenticator for t
|
||||
|
||||
During enrollment, the user supplies an email address if one is not already known, then confirms ownership by entering a one-time code.
|
||||
|
||||
The enrolled email address can later be used with the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
The enrolled email address can later be used with the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -32,9 +32,9 @@ For SMTP requirements and global email delivery settings, see [Email configurati
|
||||
|
||||
## Custom templates
|
||||
|
||||
This stage supports custom email templates in the same way as the [Email stage](../email/index.md#custom-templates). Mount your custom templates into authentik's template directory, and they will appear in the stage's **Template** dropdown.
|
||||
This stage supports custom email templates in the same way as the [Email stage](../email/index.mdx#custom-templates). Mount your custom templates into authentik's template directory, and they will appear in the stage's **Template** dropdown.
|
||||
|
||||
For the full mounting instructions (Docker Compose and Kubernetes), a list of available template variables, and an example template, see [Custom templates](../email/index.md#custom-templates) in the Email stage documentation.
|
||||
For the full mounting instructions (Docker Compose and Kubernetes), a list of available template variables, and an example template, see [Custom templates](../email/index.mdx#custom-templates) in the Email stage documentation.
|
||||
|
||||
:::info
|
||||
If a custom template does not appear in the **Template** selector, check the worker container logs. Templates are discovered when the stage configuration form loads.
|
||||
@@ -44,10 +44,10 @@ If a custom template does not appear in the **Template** selector, check the wor
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user should add an email authenticator.
|
||||
|
||||
To use the enrolled address during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **Email** device class.
|
||||
To use the enrolled address during login, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the authentication flow and allow the **Email** device class.
|
||||
|
||||
## Notes
|
||||
|
||||
- If **Use global connection settings** is enabled, configure the global email settings first. See the installation docs for [Docker Compose](../../../../install-config/install/docker-compose#email-configuration-optional-but-recommended) and [Kubernetes](../../../../install-config/install/kubernetes#email-configuration-optional-but-recommended).
|
||||
- This stage is separate from the general-purpose [Email stage](../email/index.md), which is used for email verification and recovery.
|
||||
- This stage is separate from the general-purpose [Email stage](../email/index.mdx), which is used for email verification and recovery.
|
||||
- If the user already has an email address on their account, authentik can use that address during enrollment instead of prompting for a new address.
|
||||
@@ -5,14 +5,14 @@ support_level: deprecated
|
||||
---
|
||||
|
||||
:::warning Deprecated
|
||||
This stage is deprecated in favor of the [Google Chrome connector](../../../../endpoint-devices/device-compliance/connectors/google-chrome.md) used with the [Endpoint Devices](../../../../endpoint-devices/index.mdx) feature set.
|
||||
This stage is deprecated in favor of the [Google Chrome connector](../../../../endpoint-devices/device-compliance/connectors/google-chrome.mdx) used with the [Endpoint Devices](../../../../endpoint-devices/index.mdx) feature set.
|
||||
:::
|
||||
|
||||
The Google Chrome Device Trust Authenticator Stage verifies a Chrome browser by using the Chrome Verified Access API.
|
||||
|
||||
## About the Google Chrome Device Trust authenticator stage
|
||||
|
||||
This stage validates Chrome Enterprise Device Trust signals from the user's browser. Unlike other authenticator setup stages, it does not enroll a reusable MFA device for later validation through the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
This stage validates Chrome Enterprise Device Trust signals from the user's browser. Unlike other authenticator setup stages, it does not enroll a reusable MFA device for later validation through the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
It was designed to integrate Chrome browsers and ChromeOS devices with authentik as the identity provider so access decisions could take device posture into account.
|
||||
|
||||
@@ -28,7 +28,7 @@ Typical use cases included remote-work, contractor, and BYOD environments where
|
||||
|
||||
Bind this stage directly into a flow where Chrome browser verification should happen.
|
||||
|
||||
Compared to the newer [Endpoint stage](../endpoint/index.md), this stage is Chrome-specific and relies on the legacy Device Trust integration path.
|
||||
Compared to the newer [Endpoint stage](../endpoint/index.mdx), this stage is Chrome-specific and relies on the legacy Device Trust integration path.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -61,4 +61,4 @@ More concretely:
|
||||
|
||||
### Why this stage is different
|
||||
|
||||
This stage verifies the current Chrome browser directly and does not create a reusable MFA enrollment that is later selected by the Authenticator Validation stage. That difference is why the newer [Endpoint stage](../endpoint/index.md) is a better long-term replacement for most deployments.
|
||||
This stage verifies the current Chrome browser directly and does not create a reusable MFA enrollment that is later selected by the Authenticator Validation stage. That difference is why the newer [Endpoint stage](../endpoint/index.mdx) is a better long-term replacement for most deployments.
|
||||
@@ -8,7 +8,7 @@ The SMS Authenticator Setup stage enrolls an SMS-based authenticator for the cur
|
||||
|
||||
This stage stores a phone number, enabling one-time codes to be sent via SMS.
|
||||
|
||||
In normal mode, the enrolled phone number can later be used with the [Authenticator Validation stage](../authenticator_validate/index.md). In **verify only** mode, the stage only verifies ownership of a phone number during enrollment and stores a hash instead of the number itself.
|
||||
In normal mode, the enrolled phone number can later be used with the [Authenticator Validation stage](../authenticator_validate/index.mdx). In **verify only** mode, the stage only verifies ownership of a phone number during enrollment and stores a hash instead of the number itself.
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -27,9 +27,9 @@ In normal mode, the enrolled phone number can later be used with the [Authentica
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user should add an SMS authenticator.
|
||||
|
||||
To require SMS during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **SMS** device class.
|
||||
To require SMS during login, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the authentication flow and allow the **SMS** device class.
|
||||
|
||||
If you enable **Verify only**, phone numbers enrolled through this stage cannot be used by the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
If you enable **Verify only**, phone numbers enrolled through this stage cannot be used by the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -86,7 +86,7 @@ return {
|
||||
|
||||
### Limiting phone numbers
|
||||
|
||||
To control which phone numbers are accepted, collect the number in a [Prompt stage](../prompt/index.md) and validate it with an expression policy before this stage runs. If a prompt field uses the key `phone`, the SMS setup stage will read that value from `prompt_data` instead of prompting the user again.
|
||||
To control which phone numbers are accepted, collect the number in a [Prompt stage](../prompt/index.mdx) and validate it with an expression policy before this stage runs. If a prompt field uses the key `phone`, the SMS setup stage will read that value from `prompt_data` instead of prompting the user again.
|
||||
|
||||
Example expression policy:
|
||||
|
||||
@@ -8,7 +8,7 @@ The Static Authenticator Setup stage creates one-time backup codes for a user. T
|
||||
|
||||
This stage enrolls static backup codes for the current user and generates a set of recovery codes. Each code can be used once.
|
||||
|
||||
Because static codes are a device class supported by the [Authenticator Validation stage](../authenticator_validate/index.md), they are usually added as a backup factor rather than the primary factor.
|
||||
Because static codes are a device class supported by the [Authenticator Validation stage](../authenticator_validate/index.mdx), they are usually added as a backup factor rather than the primary factor.
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -21,7 +21,7 @@ Because static codes are a device class supported by the [Authenticator Validati
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user is already authenticated or otherwise identified.
|
||||
|
||||
To use the generated backup codes during authentication, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the login flow and allow the **Static** device class.
|
||||
To use the generated backup codes during authentication, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the login flow and allow the **Static** device class.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -8,7 +8,7 @@ The TOTP Authenticator Setup stage enrolls a time-based one-time password authen
|
||||
|
||||
This stage creates a TOTP authenticator for the current user and presents a standard OTP configuration URL that authenticator apps can scan or import.
|
||||
|
||||
The enrolled TOTP authenticator can then be used with the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
The enrolled TOTP authenticator can then be used with the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -20,7 +20,7 @@ The enrolled TOTP authenticator can then be used with the [Authenticator Validat
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user can add a TOTP authenticator.
|
||||
|
||||
To require that authenticator during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **TOTP** device class.
|
||||
To require that authenticator during login, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the authentication flow and allow the **TOTP** device class.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -8,12 +8,12 @@ The Authenticator Validation stage validates an already enrolled authenticator.
|
||||
|
||||
This stage is used during authentication after a user has already enrolled one or more authenticators with a setup stage, such as:
|
||||
|
||||
- [Duo Authenticator Setup stage](../authenticator_duo/index.md)
|
||||
- [Email Authenticator Setup stage](../authenticator_email/index.md)
|
||||
- [SMS Authenticator Setup stage](../authenticator_sms/index.md)
|
||||
- [Static Authenticator Setup stage](../authenticator_static/index.md)
|
||||
- [TOTP Authenticator Setup stage](../authenticator_totp/index.md)
|
||||
- [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.md)
|
||||
- [Duo Authenticator Setup stage](../authenticator_duo/index.mdx)
|
||||
- [Email Authenticator Setup stage](../authenticator_email/index.mdx)
|
||||
- [SMS Authenticator Setup stage](../authenticator_sms/index.mdx)
|
||||
- [Static Authenticator Setup stage](../authenticator_static/index.mdx)
|
||||
- [TOTP Authenticator Setup stage](../authenticator_totp/index.mdx)
|
||||
- [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.mdx)
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -34,7 +34,7 @@ This stage is used during authentication after a user has already enrolled one o
|
||||
|
||||
## Flow integration
|
||||
|
||||
This stage normally appears in authentication flows after [Identification](../identification/index.md) and [Password](../password/index.md), and before [User Login](../user_login/index.md).
|
||||
This stage normally appears in authentication flows after [Identification](../identification/index.mdx) and [Password](../password/index.mdx), and before [User Login](../user_login/index.mdx).
|
||||
|
||||
If **Not configured action** is set to **Configure**, the stage can bootstrap enrollment by injecting one or more authenticator setup stages into the running flow.
|
||||
|
||||
@@ -103,9 +103,9 @@ To build a dedicated passwordless flow:
|
||||
1. Create an **Authentication** flow.
|
||||
2. Add an Authenticator Validation stage that allows the **WebAuthn** device class.
|
||||
3. Add any extra verification stages you still require.
|
||||
4. End the flow with a [User Login stage](../user_login/index.md).
|
||||
4. End the flow with a [User Login stage](../user_login/index.mdx).
|
||||
|
||||
If you want users to choose a passkey directly from the browser's autofill UI on the identification screen, configure **Passkey autofill** in the [Identification stage](../identification/index.md#passkey-autofill-webauthn-conditional-ui). This requires a discoverable credential, also known as a resident key.
|
||||
If you want users to choose a passkey directly from the browser's autofill UI on the identification screen, configure **Passkey autofill** in the [Identification stage](../identification/index.mdx#passkey-autofill-webauthn-conditional-ui). This requires a discoverable credential, also known as a resident key.
|
||||
|
||||
Users can either access the passwordless flow directly or reach it through an Identification stage's **Passwordless flow** link.
|
||||
|
||||
@@ -133,7 +133,7 @@ If the user has multiple compatible authenticators, authentik lets them choose o
|
||||
|
||||
The available device-type entries are populated from the [FIDO Alliance Metadata Service](https://fidoalliance.org/metadata/) data and additional AAGUID metadata bundled with the authentik release. This is useful when you need to limit authentication to specific hardware families or compliance profiles.
|
||||
|
||||
These restrictions only apply to WebAuthn devices that have a stored device type. Devices enrolled in authentik 2024.4 or later store this information when the authenticator returns a known AAGUID. Older WebAuthn enrollments or devices without a stored type cannot be matched by this filter. To enforce a device-type policy for enrollment and later authentication, configure the same allowlist on the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.md) and have users re-enroll devices that predate stored device types.
|
||||
These restrictions only apply to WebAuthn devices that have a stored device type. Devices enrolled in authentik 2024.4 or later store this information when the authenticator returns a known AAGUID. Older WebAuthn enrollments or devices without a stored type cannot be matched by this filter. To enforce a device-type policy for enrollment and later authentication, configure the same allowlist on the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.mdx) and have users re-enroll devices that predate stored device types.
|
||||
|
||||
### Throttling
|
||||
|
||||
@@ -12,7 +12,7 @@ This stage supports common WebAuthn authenticator types, including:
|
||||
- platform authenticators such as Windows Hello, Touch ID, or Face ID
|
||||
- passkeys stored by operating systems or password managers
|
||||
|
||||
Enrolled authenticators can later be used with the [Authenticator Validation stage](../authenticator_validate/index.md).
|
||||
Enrolled authenticators can later be used with the [Authenticator Validation stage](../authenticator_validate/index.mdx).
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -29,9 +29,9 @@ Enrolled authenticators can later be used with the [Authenticator Validation sta
|
||||
|
||||
Use this stage in an enrollment or user-settings flow where the user should register a passkey or hardware key.
|
||||
|
||||
To require those devices during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **WebAuthn** device class.
|
||||
To require those devices during login, add an [Authenticator Validation stage](../authenticator_validate/index.mdx) to the authentication flow and allow the **WebAuthn** device class.
|
||||
|
||||
If you want passkey autofill on the login form itself, configure the [Identification stage](../identification/index.md#passkey-autofill-webauthn-conditional-ui) to reference a WebAuthn-capable Authenticator Validation stage.
|
||||
If you want passkey autofill on the login form itself, configure the [Identification stage](../identification/index.mdx#passkey-autofill-webauthn-conditional-ui) to reference a WebAuthn-capable Authenticator Validation stage.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -8,7 +8,7 @@ The Captcha stage adds CAPTCHA verification to a flow by using Google reCAPTCHA
|
||||
|
||||
This stage verifies that the current interaction appears human before the flow continues.
|
||||
|
||||
It can either be bound to a flow or embedded inside the [Identification stage](../identification/index.md) by setting the Identification stage's **Captcha stage** option.
|
||||
It can either be bound to a flow or embedded inside the [Identification stage](../identification/index.mdx) by setting the Identification stage's **Captcha stage** option.
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -26,7 +26,7 @@ It can either be bound to a flow or embedded inside the [Identification stage](.
|
||||
|
||||
Use this stage anywhere a flow should require a CAPTCHA check, especially in enrollment, recovery, or other public-facing flows.
|
||||
|
||||
If you embed it in the [Identification stage](../identification/index.md), configure the CAPTCHA provider for invisible or background use.
|
||||
If you embed it in the [Identification stage](../identification/index.mdx), configure the CAPTCHA provider for invisible or background use.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -19,7 +19,7 @@ Bind this stage where a flow should stop after a policy or earlier stage determi
|
||||
## Notes
|
||||
|
||||
:::caution
|
||||
To use this stage effectively, make sure **Evaluate when flow is planned** is disabled on the stage binding. See [Planning and stage policies](../../flow/planner.md#planning-and-stage-policies).
|
||||
To use this stage effectively, make sure **Evaluate when flow is planned** is disabled on the stage binding. See [Planning and stage policies](../../flow/planner.mdx#planning-and-stage-policies).
|
||||
:::
|
||||
|
||||
If the binding is evaluated during flow planning, the denial can happen earlier than intended and skip the checks that were meant to decide whether the user should be denied.
|
||||
@@ -14,9 +14,9 @@ This stage lets the user identify themselves by username, email address, UPN, or
|
||||
- **Username**
|
||||
- **Email**
|
||||
- **UPN**
|
||||
- **Password stage**: optional [Password stage](../password/index.md) to render inline instead of as a separate step.
|
||||
- **Captcha stage**: optional [Captcha stage](../captcha/index.md) to run as part of identification.
|
||||
- **WebAuthn Authenticator Validation Stage**: optional [Authenticator Validation stage](../authenticator_validate/index.md) used for passkey autofill.
|
||||
- **Password stage**: optional [Password stage](../password/index.mdx) to render inline instead of as a separate step.
|
||||
- **Captcha stage**: optional [Captcha stage](../captcha/index.mdx) to run as part of identification.
|
||||
- **WebAuthn Authenticator Validation Stage**: optional [Authenticator Validation stage](../authenticator_validate/index.mdx) used for passkey autofill.
|
||||
- **Case-insensitive matching**: match identifiers regardless of case.
|
||||
- **Show matched user**: display the matched user's username and avatar after a valid identifier is entered.
|
||||
- **Pretend user exists**: continue even when the entered identifier does not match a real user.
|
||||
@@ -51,7 +51,7 @@ If you set a **Captcha stage** here, configure that CAPTCHA for invisible or bac
|
||||
|
||||
### Pretend user exists
|
||||
|
||||
When enabled, invalid identifiers still let the flow continue as long as the format is valid for the selected field type. Stages such as [Password](../password/index.md) and [Email](../email/index.md) are aware of this behavior and handle the synthetic pending user safely.
|
||||
When enabled, invalid identifiers still let the flow continue as long as the format is valid for the selected field type. Stages such as [Password](../password/index.mdx) and [Email](../email/index.mdx) are aware of this behavior and handle the synthetic pending user safely.
|
||||
|
||||
### Source behavior
|
||||
|
||||
@@ -82,9 +82,9 @@ authentik automatically falls back to the normal identification flow when passke
|
||||
|
||||
#### Configuration
|
||||
|
||||
1. Create or edit an [Authenticator Validation stage](../authenticator_validate/index.md) that allows the **WebAuthn** device class.
|
||||
1. Create or edit an [Authenticator Validation stage](../authenticator_validate/index.mdx) that allows the **WebAuthn** device class.
|
||||
2. Set the Identification stage's **WebAuthn Authenticator Validation Stage** to that stage.
|
||||
3. Make sure users have already enrolled a WebAuthn authenticator, for example with the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.md).
|
||||
3. Make sure users have already enrolled a WebAuthn authenticator, for example with the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.mdx).
|
||||
|
||||
If the user has multiple passkeys, the browser shows its own picker. In the default authentication flow, authentik skips the MFA validation stage after a passkey login with an expression policy; adjust that policy if you still want a second factor after passkey login.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Stages
|
||||
---
|
||||
|
||||
Stages are one of the fundamental building blocks in authentik, along with [flows](../flow/index.md) and [policies](../../../customize/policies/index.md).
|
||||
Stages are one of the fundamental building blocks in authentik, along with [flows](../flow/index.mdx) and [policies](../../../customize/policies/index.mdx).
|
||||
|
||||
A stage represents a single verification or logic step within a flow. You can bind one or more stages to a flow to create a customized, flexible login and authentication process.
|
||||
|
||||
@@ -49,12 +49,12 @@ After creating the stage, you can use bindings to determine whether the stage ru
|
||||
|
||||
A stage binding connects a stage to a flow. The binding adds that stage as a step in the flow.
|
||||
|
||||
You can use bindings to determine which [stages](../stages/index.md) are presented to a user or group.
|
||||
You can use bindings to determine which [stages](../stages/index.mdx) are presented to a user or group.
|
||||
|
||||
For an overview of binding types and behavior, see [Bindings in authentik](../../bindings-overview/index.md).
|
||||
For an overview of binding types and behavior, see [Bindings in authentik](../../bindings-overview/index.mdx).
|
||||
|
||||
:::info
|
||||
Some stages and flows do not allow user or group bindings. In some authentication or enrollment scenarios, the [flow plan](../flow/planner.md) does not yet know the current user or group.
|
||||
Some stages and flows do not allow user or group bindings. In some authentication or enrollment scenarios, the [flow plan](../flow/planner.mdx) does not yet know the current user or group.
|
||||
:::
|
||||
|
||||
### Bind a stage to a flow
|
||||
@@ -72,7 +72,7 @@ To bind a stage to a flow, follow these steps:
|
||||
|
||||
There are several ways to control access to a specific stage of a flow:
|
||||
|
||||
- Bind a policy to a stage binding. See [Bind a policy to a stage binding](../../../customize/policies/working_with_policies.md#bind-a-policy-to-a-stage-binding).
|
||||
- Bind a policy to a stage binding. See [Bind a policy to a stage binding](../../../customize/policies/working_with_policies.mdx#bind-a-policy-to-a-stage-binding).
|
||||
- Bind a user or group to the stage binding. See [Bind users and groups to a flow's stage binding](#bind-users-and-groups-to-a-flows-stage-binding).
|
||||
|
||||
### Bind users and groups to a flow's stage binding
|
||||
@@ -91,4 +91,4 @@ To bind a user or a group to a stage binding for a specific flow, follow these s
|
||||
8. In the drop-down list, select the group or user.
|
||||
9. Optionally, configure additional settings for the binding, and then click **Create** to create the binding and close the box.
|
||||
|
||||
Learn more about the different types of [bindings](../../bindings-overview/index.md) in authentik and [working with them](../../bindings-overview/work-with-bindings.md).
|
||||
Learn more about the different types of [bindings](../../bindings-overview/index.mdx) in authentik and [working with them](../../bindings-overview/work-with-bindings.mdx).
|
||||
@@ -24,7 +24,7 @@ Users can enter the flow with an invitation token by using a URL like:
|
||||
https://authentik.example/if/flow/your-enrollment-flow/?itoken=invitation-token
|
||||
```
|
||||
|
||||
You can also collect the token with a [Prompt stage](../prompt/index.md) by using a prompt field with the key `token`.
|
||||
You can also collect the token with a [Prompt stage](../prompt/index.mdx) by using a prompt field with the key `token`.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -97,7 +97,7 @@ See the [Envoy mTLS documentation](https://www.envoyproxy.io/docs/envoy/latest/s
|
||||
|
||||
#### No reverse proxy
|
||||
|
||||
If authentik terminates TLS itself, configure the trusted client certificate authorities on the active [brand](../../../../customize/branding/index.md#client-certificates).
|
||||
If authentik terminates TLS itself, configure the trusted client certificate authorities on the active [brand](../../../../customize/branding/index.mdx#client-certificates).
|
||||
|
||||
### Stage setup outline
|
||||
|
||||
@@ -23,9 +23,9 @@ The stage supports authentik's built-in password database, app passwords, LDAP-b
|
||||
|
||||
## Flow integration
|
||||
|
||||
This stage is typically bound after an [Identification](../identification/index.md) stage and before an [Authenticator Validation](../authenticator_validate/index.md) or [User Login](../user_login/index.md) stage.
|
||||
This stage is typically bound after an [Identification](../identification/index.mdx) stage and before an [Authenticator Validation](../authenticator_validate/index.mdx) or [User Login](../user_login/index.mdx) stage.
|
||||
|
||||
If the [Identification stage](../identification/index.md) has its **Password stage** option set, the password prompt is rendered as part of the identification step and the Password stage should not also be bound separately in the same flow.
|
||||
If the [Identification stage](../identification/index.mdx) has its **Password stage** option set, the password prompt is rendered as part of the identification step and the Password stage should not also be bound separately in the same flow.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -37,10 +37,10 @@ Service accounts have automatically generated app passwords. Those can be viewed
|
||||
|
||||
There are two common ways to avoid prompting for a password:
|
||||
|
||||
- Use an [Authenticator Validation](../authenticator_validate/index.md#passwordless-authentication) stage with WebAuthn for a dedicated passwordless flow.
|
||||
- Use an [Authenticator Validation](../authenticator_validate/index.mdx#passwordless-authentication) stage with WebAuthn for a dedicated passwordless flow.
|
||||
- Conditionally skip the Password stage by binding a policy to its stage binding.
|
||||
|
||||
If you want users to be able to pick a passkey from the browser's passkey/autofill UI without entering a username first, configure **Passkey autofill (WebAuthn conditional UI)** in the [Identification stage](../identification/index.md#passkey-autofill-webauthn-conditional-ui). This is separate from configuring a dedicated passwordless flow, and can be used alongside normal identification flows.
|
||||
If you want users to be able to pick a passkey from the browser's passkey/autofill UI without entering a username first, configure **Passkey autofill (WebAuthn conditional UI)** in the [Identification stage](../identification/index.mdx#passkey-autofill-webauthn-conditional-ui). This is separate from configuring a dedicated passwordless flow, and can be used alongside normal identification flows.
|
||||
|
||||
### Dynamically skip a Password stage
|
||||
|
||||
@@ -52,8 +52,8 @@ To configure this setup:
|
||||
2. Navigate to **Customization** > **Policies** and create an [Expression Policy](../../../../customize/policies/types/expression/index.mdx).
|
||||
3. Configure the expression so that it returns `True` only when the Password stage should run. Use one of the expressions below, depending on the authenticator type.
|
||||
4. Navigate to **Flows and Stages** > **Flows** and open your authentication flow.
|
||||
5. Open the **Stage Bindings** tab, expand the Password stage binding, and bind the Expression Policy there. Do not bind it to the flow itself or directly to the stage object. For more background, see [Bind a policy to a stage binding](../../../../customize/policies/working_with_policies.md#bind-a-policy-to-a-stage-binding).
|
||||
6. On the Password stage binding, enable **Evaluate when stage is run**. Disable **Evaluate when flow is planned** unless the user is already known before the flow starts. See [Planning and stage policies](../../flow/planner.md#planning-and-stage-policies).
|
||||
5. Open the **Stage Bindings** tab, expand the Password stage binding, and bind the Expression Policy there. Do not bind it to the flow itself or directly to the stage object. For more background, see [Bind a policy to a stage binding](../../../../customize/policies/working_with_policies.mdx#bind-a-policy-to-a-stage-binding).
|
||||
6. On the Password stage binding, enable **Evaluate when stage is run**. Disable **Evaluate when flow is planned** unless the user is already known before the flow starts. See [Planning and stage policies](../../flow/planner.mdx#planning-and-stage-policies).
|
||||
|
||||
#### WebAuthn
|
||||
|
||||
@@ -70,8 +70,8 @@ Use this stage anywhere a flow needs user-provided input.
|
||||
|
||||
Common follow-ups include:
|
||||
|
||||
- A [User Write](../user_write/index.md) stage to persist collected values
|
||||
- An [Email](../email/index.md) or [Invitation](../invitation/index.md) stage to act on collected data
|
||||
- A [User Write](../user_write/index.mdx) stage to persist collected values
|
||||
- An [Email](../email/index.mdx) or [Invitation](../invitation/index.mdx) stage to act on collected data
|
||||
- Policy checks that read from `request.context["prompt_data"]`
|
||||
|
||||
## Notes
|
||||
@@ -3,7 +3,7 @@ title: Source stage
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
The Source stage sends the user to an [OAuth](../../../../users-sources/sources/protocols/oauth/index.mdx) or [SAML](../../../../users-sources/sources/protocols/saml/index.md) source before returning to the flow.
|
||||
The Source stage sends the user to an [OAuth](../../../../users-sources/sources/protocols/oauth/index.mdx) or [SAML](../../../../users-sources/sources/protocols/saml/index.mdx) source before returning to the flow.
|
||||
|
||||
## About the source stage
|
||||
|
||||
@@ -11,11 +11,11 @@ Use this stage when an external identity provider should be part of the current
|
||||
|
||||
Common examples include:
|
||||
|
||||
- Authenticating against a legacy IdP such as [Microsoft Entra ID](../../../../users-sources/sources/social-logins/entra-id/oauth/index.mdx), [Google Workspace](../../../../users-sources/sources/social-logins/google/workspace/index.md), or [Okta](../../../../users-sources/sources/social-logins/okta/index.md) during an IdP migration and then using the returned identity and attributes inside authentik
|
||||
- Authenticating against a legacy IdP such as [Microsoft Entra ID](../../../../users-sources/sources/social-logins/entra-id/oauth/index.mdx), [Google Workspace](../../../../users-sources/sources/social-logins/google/workspace/index.mdx), or [Okta](../../../../users-sources/sources/social-logins/okta/index.mdx) during an IdP migration and then using the returned identity and attributes inside authentik
|
||||
- Routing users through an external OAuth or SAML identity provider
|
||||
- Sending users through a custom device-health or posture-check system before continuing
|
||||
|
||||
For pure authentication or enrollment, an [OAuth](../../../../users-sources/sources/protocols/oauth/index.mdx) or [SAML](../../../../users-sources/sources/protocols/saml/index.md) source can also be used directly without a Source stage. Use the Source stage when that external step needs to be embedded inside another authentik flow.
|
||||
For pure authentication or enrollment, an [OAuth](../../../../users-sources/sources/protocols/oauth/index.mdx) or [SAML](../../../../users-sources/sources/protocols/saml/index.mdx) source can also be used directly without a Source stage. Use the Source stage when that external step needs to be embedded inside another authentik flow.
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -32,7 +32,7 @@ The configured source must be a browser-based source such as OAuth or SAML. LDAP
|
||||
|
||||
### Important source-flow behavior
|
||||
|
||||
Do not bind a [User Login stage](../user_login/index.md) to the source's own authentication or enrollment flow.
|
||||
Do not bind a [User Login stage](../user_login/index.mdx) to the source's own authentication or enrollment flow.
|
||||
|
||||
The Source stage resumes the original flow by appending a dynamic in-memory stage to the source flow. If the source flow logs the user in directly, the original flow will not resume correctly.
|
||||
|
||||
@@ -24,8 +24,8 @@ Use this stage near the end of flows that should create an authenticated browser
|
||||
|
||||
Common placements include:
|
||||
|
||||
- after a [Password](../password/index.md) or [Authenticator Validation](../authenticator_validate/index.md) stage in authentication flows
|
||||
- after a [User Write](../user_write/index.md) stage in enrollment flows
|
||||
- after a [Password](../password/index.mdx) or [Authenticator Validation](../authenticator_validate/index.mdx) stage in authentication flows
|
||||
- after a [User Write](../user_write/index.mdx) stage in enrollment flows
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: User logout stage
|
||||
---
|
||||
|
||||
The User Logout stage ends the user's authentik session and, if configured, initiates [Single Logout](../../../providers/single-logout/index.md).
|
||||
The User Logout stage ends the user's authentik session and, if configured, initiates [Single Logout](../../../providers/single-logout/index.mdx).
|
||||
|
||||
## About the user logout stage
|
||||
|
||||
@@ -8,7 +8,7 @@ The User Write stage writes data from the current flow context into a user objec
|
||||
|
||||
This stage updates the current `pending_user`, or creates a new user if the flow does not already have one and the configured creation mode allows it.
|
||||
|
||||
It is commonly used in enrollment, recovery, and profile-update flows after a [Prompt stage](../prompt/index.md) has collected input into `prompt_data`.
|
||||
It is commonly used in enrollment, recovery, and profile-update flows after a [Prompt stage](../prompt/index.mdx) has collected input into `prompt_data`.
|
||||
|
||||
## Configuration options
|
||||
|
||||
@@ -20,9 +20,9 @@ It is commonly used in enrollment, recovery, and profile-update flows after a [P
|
||||
|
||||
## Flow integration
|
||||
|
||||
Use this stage after one or more stages that populate flow context, usually a [Identification stage](../identification/index.md), [Prompt stage](../prompt/index.md), or [Email stage](../email/index.md).
|
||||
Use this stage after one or more stages that populate flow context, usually a [Identification stage](../identification/index.mdx), [Prompt stage](../prompt/index.mdx), or [Email stage](../email/index.mdx).
|
||||
|
||||
In enrollment flows, this stage is often followed by a [User Login](../user_login/index.md) stage so the newly created user is immediately signed in.
|
||||
In enrollment flows, this stage is often followed by a [User Login](../user_login/index.mdx) stage so the newly created user is immediately signed in.
|
||||
|
||||
## Notes
|
||||
|
||||
@@ -12,7 +12,7 @@ You can access the embedded outpost on the same ports as authentik itself, `9000
|
||||
|
||||
Use the embedded outpost when you are using the proxy provider and want the simplest deployment model. It is a good fit when authentik is already behind a reverse proxy and you want proxy provider traffic to be handled by the same authentik deployment, without a separate outpost deployment.
|
||||
|
||||
Use a [managed outpost](../index.mdx) instead when you want authentik to deploy and update a separate outpost through the [Docker](../integrations/docker.md) or [Kubernetes](../integrations/kubernetes.md) integrations, or when you want the outpost lifecycle to be separate from the core server.
|
||||
Use a [managed outpost](../index.mdx) instead when you want authentik to deploy and update a separate outpost through the [Docker](../integrations/docker.mdx) or [Kubernetes](../integrations/kubernetes.mdx) integrations, or when you want the outpost lifecycle to be separate from the core server.
|
||||
|
||||
If the embedded outpost does not fit your deployment, you can ignore it and use a [managed outpost](../index.mdx) instead.
|
||||
|
||||
@@ -28,7 +28,7 @@ Make sure that you set a full URL. A hostname or FQDN by itself does not work.
|
||||
|
||||
Most other outpost configuration options also apply to the embedded outpost, except for items that are marked as `non-embedded`.
|
||||
|
||||
import Configuration from "../_config.md";
|
||||
import Configuration from "../_config.mdx";
|
||||
|
||||
<Configuration />
|
||||
|
||||
|
||||
@@ -7,10 +7,10 @@ An outpost is a single deployment of an authentik component, essentially a servi
|
||||
|
||||
An outpost is required if you use any of the following types of providers with your application:
|
||||
|
||||
- [LDAP Provider](../providers/ldap/index.md)
|
||||
- [Proxy Provider](../providers/proxy/index.md)
|
||||
- [LDAP Provider](../providers/ldap/index.mdx)
|
||||
- [Proxy Provider](../providers/proxy/index.mdx)
|
||||
- [RADIUS Provider](../providers/radius/index.mdx)
|
||||
- [RAC Provider](../providers/rac/index.md)
|
||||
- [RAC Provider](../providers/rac/index.mdx)
|
||||
|
||||
These types of providers use an outpost for increased flexibility and speed. Instead of the provider logic being implemented in authentik Core, these providers use an outpost to handle the logic, which provides improved performance.
|
||||
|
||||
@@ -42,21 +42,21 @@ Upon creation, a service account and a token is generated. The service account o
|
||||
|
||||
authentik can manage the deployment, updating, and general lifecycle of an outpost. To communicate with the underlying platforms on which the outpost is deployed, authentik has several built-in integrations.
|
||||
|
||||
- If you've deployed authentik on Docker Compose, authentik automatically creates an integration for the local docker socket (See [Docker](./integrations/docker.md)).
|
||||
- If you've deployed authentik on Kubernetes, with `kubernetesIntegration` set to true (default), authentik automatically creates an integration for the local Kubernetes Cluster (see [Kubernetes](./integrations/kubernetes.md)).
|
||||
- If you've deployed authentik on Docker Compose, authentik automatically creates an integration for the local docker socket (See [Docker](./integrations/docker.mdx)).
|
||||
- If you've deployed authentik on Kubernetes, with `kubernetesIntegration` set to true (default), authentik automatically creates an integration for the local Kubernetes Cluster (see [Kubernetes](./integrations/kubernetes.mdx)).
|
||||
|
||||
To deploy an outpost with these integrations, select them during the creation of an outpost. A background task is started, which creates the container/deployment. The outpost deployment can be monitored from the **Dashboards > System Tasks** page in the Admin interface.
|
||||
|
||||
To deploy an outpost manually, see:
|
||||
|
||||
- [Kubernetes](./manual-deploy-kubernetes.md)
|
||||
- [Docker Compose](./manual-deploy-docker-compose.md)
|
||||
- [Kubernetes](./manual-deploy-kubernetes.mdx)
|
||||
- [Docker Compose](./manual-deploy-docker-compose.mdx)
|
||||
|
||||
## Configuration
|
||||
|
||||
Outposts fetch their configuration from authentik. Below are all the options you can set, and how they influence the outpost.
|
||||
|
||||
import Configuration from "./_config.md";
|
||||
import Configuration from "./_config.mdx";
|
||||
|
||||
<Configuration />
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Kubernetes
|
||||
|
||||
The Kubernetes integration automatically deploys and manages outposts in a Kubernetes cluster.
|
||||
|
||||
Compared with a [manual Kubernetes deployment](../manual-deploy-kubernetes.md), this integration keeps managed outposts aligned with authentik updates and reduces the amount of cluster-side configuration that you need to maintain.
|
||||
Compared with a [manual Kubernetes deployment](../manual-deploy-kubernetes.mdx), this integration keeps managed outposts aligned with authentik updates and reduces the amount of cluster-side configuration that you need to maintain.
|
||||
|
||||
## Created resources
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Upgrading an Outpost
|
||||
---
|
||||
|
||||
Outposts deployed using the [Docker](./integrations/docker.md) or [Kubernetes](./integrations/kubernetes.md) integrations are managed by authentik and are upgraded automatically. Outposts deployed manually via [Docker](./manual-deploy-docker-compose.md) or [Kubernetes](./manual-deploy-kubernetes.md) must be upgraded by updating the outpost's image tag to the new version.
|
||||
Outposts deployed using the [Docker](./integrations/docker.mdx) or [Kubernetes](./integrations/kubernetes.mdx) integrations are managed by authentik and are upgraded automatically. Outposts deployed manually via [Docker](./manual-deploy-docker-compose.mdx) or [Kubernetes](./manual-deploy-kubernetes.mdx) must be upgraded by updating the outpost's image tag to the new version.
|
||||
|
||||
To check if any outposts are out-of-date, navigate to **Applications** > **Outposts** and look for a message in the **Health and Version** column.
|
||||
|
||||
@@ -3,9 +3,9 @@ title: Configure Entra ID
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using an Entra ID provider, see the [Entra ID Overview](./index.md) documentation.
|
||||
For more information about using an Entra ID provider, see the [Entra ID Overview](./index.mdx) documentation.
|
||||
|
||||
Your Entra ID tenant must be configured before you [create an Entra ID provider](./create-entra-provider.md).
|
||||
Your Entra ID tenant must be configured before you [create an Entra ID provider](./create-entra-provider.mdx).
|
||||
|
||||
This involves creating an app registration, generating a secret, and configuring the required API permissions.
|
||||
|
||||
@@ -14,7 +14,7 @@ When the default `authentik default Microsoft Entra Mapping: User` property mapp
|
||||
|
||||
In which case, you must configure each user's email domain as a [verified custom domain in Entra ID](https://learn.microsoft.com/en-us/entra/identity/users/domains-manage#add-custom-domain-names-to-your-microsoft-entra-organization); otherwise, provisioning fails. The tenant's default `onmicrosoft.com` domain (e.g., `@<tenant name>.onmicrosoft.com`), is considered a verified domain.
|
||||
|
||||
Alternatively, if you need to provision users with email domains that you don't control, refer to [Email handling](./create-entra-provider.md#email-handling) for more information.
|
||||
Alternatively, if you need to provision users with email domains that you don't control, refer to [Email handling](./create-entra-provider.mdx#email-handling) for more information.
|
||||
:::
|
||||
|
||||
## Configure your Entra ID tenant
|
||||
@@ -25,13 +25,13 @@ Alternatively, if you need to provision users with email domains that you don't
|
||||
- Under **Supported account types**, select **Accounts in this organizational directory only**
|
||||
- Leave **Redirect URI** empty
|
||||
3. Click **Register**.
|
||||
4. On the app detail page, take note of the **Application (client) ID** and **Directory (tenant) ID**. These values will be required when you [create the Entra ID provider](./create-entra-provider.md) in authentik.
|
||||
4. On the app detail page, take note of the **Application (client) ID** and **Directory (tenant) ID**. These values will be required when you [create the Entra ID provider](./create-entra-provider.mdx) in authentik.
|
||||
5. Next, in the near-left navigation pane, click on **Certificates and Secrets**.
|
||||
6. On the **Client secrets** tab, click **New client secret** and set the following configuration:
|
||||
- Provide a **Description** for the client secret
|
||||
- Set an expiry period for the secret. Please note that you will need to rotate the secret value in Entra ID and authentik upon expiry.
|
||||
7. Click **Add**.
|
||||
8. The **Value** of the client secret is shown only once. Take note of the value as it will be required when you [create the Entra ID provider](./create-entra-provider.md) in authentik.
|
||||
8. The **Value** of the client secret is shown only once. Take note of the value as it will be required when you [create the Entra ID provider](./create-entra-provider.mdx) in authentik.
|
||||
9. Next, in the near-left navigation pane, click on **API permissions**.
|
||||
10. Click **Add a permission** and select **Microsoft Graph** as the API.
|
||||
11. Select **Application permissions** as the permission type and assign the following permissions:
|
||||
@@ -42,4 +42,4 @@ Alternatively, if you need to provision users with email domains that you don't
|
||||
12. Click **Add permissions**.
|
||||
13. Under **Configured permissions**, click **Grant admin consent for default directory**.
|
||||
|
||||
Now that you have configured your Entra ID tenant, you are ready to [create an Entra ID provider](./create-entra-provider.md).
|
||||
Now that you have configured your Entra ID tenant, you are ready to [create an Entra ID provider](./create-entra-provider.mdx).
|
||||
@@ -3,11 +3,11 @@ title: Create an Entra ID provider
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using an Entra ID provider, see the [Overview](./index.md) documentation.
|
||||
For more information about using an Entra ID provider, see the [Overview](./index.mdx) documentation.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To create an Entra ID provider in authentik, you must have already [configured Entra ID](./configure-entra.md).
|
||||
To create an Entra ID provider in authentik, you must have already [configured Entra ID](./configure-entra.mdx).
|
||||
|
||||
## Create an Entra ID provider in authentik
|
||||
|
||||
@@ -17,7 +17,7 @@ To create an Entra ID provider in authentik, you must have already [configured E
|
||||
4. On the **New Microsoft Entra Provider** page, set the following configurations:
|
||||
- **Name**: provide a descriptive name (e.g. `Entra ID provider`)
|
||||
- Under **Protocol settings**:
|
||||
- **Client ID**: the Client ID that you copied when [configuring Entra ID](./configure-entra.md)
|
||||
- **Client ID**: the Client ID that you copied when [configuring Entra ID](./configure-entra.mdx)
|
||||
- **Client Secret**: the secret from Entra ID
|
||||
- **Tenant ID**: the Tenant ID from Entra ID
|
||||
- **User deletion action**: determines what authentik will do when a user is deleted from authentik
|
||||
@@ -30,7 +30,7 @@ To create an Entra ID provider in authentik, you must have already [configured E
|
||||
- **Group Property Mappings**: select any property mappings, or use the default
|
||||
|
||||
:::info Skipping certain users or groups
|
||||
The `SkipObject` exception can be used within a property mapping to prevent specific objects from being synced. Refer to the [Provider property mappings documentation](../property-mappings/index.md#skip-objects-during-synchronization) for more details.
|
||||
The `SkipObject` exception can be used within a property mapping to prevent specific objects from being synced. Refer to the [Provider property mappings documentation](../property-mappings/index.mdx#skip-objects-during-synchronization) for more details.
|
||||
:::
|
||||
|
||||
5. Click **Finish**.
|
||||
@@ -7,10 +7,10 @@ sidebar_label: "Microsoft Entra ID Provider"
|
||||
|
||||
The Entra ID provider allows you to integrate with your Entra ID tenant. It supports syncing users and groups from authentik to Entra ID, allowing authentik to act as a source of truth for all users and groups.
|
||||
|
||||
- For instructions on configuring your Entra ID tenant in prepation for creating an Entra ID provider, refer to [Configure Entra ID](./configure-entra.md).
|
||||
- For instructions on creating an Entra ID provider, refer to [Create an Entra ID provider](./create-entra-provider.md).
|
||||
- For instructions on configuring your Entra ID tenant in prepation for creating an Entra ID provider, refer to [Configure Entra ID](./configure-entra.mdx).
|
||||
- For instructions on creating an Entra ID provider, refer to [Create an Entra ID provider](./create-entra-provider.mdx).
|
||||
|
||||
If you also want to authenticate to Entra ID using authentik credentials, refer to our [Microsoft 365 SAML](/integrations/platforms/microsoft-saml/index.md) or [Microsoft 365 WS-Federation](/integrations/platforms/microsoft-ws-federation/index.md) integrations guides.
|
||||
If you also want to authenticate to Entra ID using authentik credentials, refer to our [Microsoft 365 SAML](/integrations/platforms/microsoft-saml/index.mdx) or [Microsoft 365 WS-Federation](/integrations/platforms/microsoft-ws-federation/index.mdx) integrations guides.
|
||||
|
||||
## Discovery
|
||||
|
||||
@@ -3,9 +3,9 @@ title: Configure Google Workspace
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.md) documentation.
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.mdx) documentation.
|
||||
|
||||
Your Google Workspace organization must be configured before you [create a Google Workspace provider](./create-gws-provider.md).
|
||||
Your Google Workspace organization must be configured before you [create a Google Workspace provider](./create-gws-provider.mdx).
|
||||
|
||||
## Configure your Google Workspace organization
|
||||
|
||||
@@ -87,4 +87,4 @@ The Delagated Subject user requires the following permissions:
|
||||
- Users
|
||||
- Groups
|
||||
|
||||
Now that you have configured your Google Workspace organization, you are ready to [create a Google Workspace provider](./create-gws-provider.md).
|
||||
Now that you have configured your Google Workspace organization, you are ready to [create a Google Workspace provider](./create-gws-provider.mdx).
|
||||
@@ -3,11 +3,11 @@ title: Create a Google Workspace provider
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.md) documentation.
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.mdx) documentation.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To create a Google Workspace provider in authentik, you must have already [configured Google Workspace](./configure-gws.md).
|
||||
To create a Google Workspace provider in authentik, you must have already [configured Google Workspace](./configure-gws.mdx).
|
||||
|
||||
## Create a Google Workspace provider in authentik
|
||||
|
||||
@@ -17,7 +17,7 @@ To create a Google Workspace provider in authentik, you must have already [confi
|
||||
4. On the **New Google Workspace Provider** page, set the following configurations:
|
||||
- **Name**: provide a descriptive name (e.g. `GWS provider`)
|
||||
- Under **Protocol settings**:
|
||||
- **Credentials**: paste the contents of the JSON file that you downloaded when [configuring Google Workspace](./configure-gws.md)
|
||||
- **Credentials**: paste the contents of the JSON file that you downloaded when [configuring Google Workspace](./configure-gws.mdx)
|
||||
- **Delegated Subject**: enter the email address of the Google Workspace user that all authentik actions will be delegated to
|
||||
- **Default group email domain**: enter a domain which will be used to generate the email address for groups synced from authentik to Google Workspace
|
||||
- **User deletion action**: determines what authentik will do when a user is deleted from authentik
|
||||
@@ -30,7 +30,7 @@ To create a Google Workspace provider in authentik, you must have already [confi
|
||||
- **Group Property Mappings**: select any property mappings, or use the default
|
||||
|
||||
:::info Skipping certain users or groups
|
||||
The `SkipObject` exception can be used within a property mapping to prevent specific objects from being synced. Refer to the [Provider property mappings documentation](../property-mappings/index.md#skip-objects-during-synchronization) for more details.
|
||||
The `SkipObject` exception can be used within a property mapping to prevent specific objects from being synced. Refer to the [Provider property mappings documentation](../property-mappings/index.mdx#skip-objects-during-synchronization) for more details.
|
||||
:::
|
||||
|
||||
5. Click **Finish**.
|
||||
@@ -7,8 +7,8 @@ sidebar_label: "Google Workspace Provider"
|
||||
|
||||
The Google Workspace provider allows you to integrate with your Google Workspace organization. It supports syncing users and groups from authentik to Google Workspace, allowing authentik to act as a source of truth for all users and groups.
|
||||
|
||||
- For instructions on configuring your Google Workspace organization in prepation for creating a Google Workspace provider, refer to the [Configure Google Workspace](./configure-gws.md) documentation.
|
||||
- For instructions on creating a Google Workspace provider, refer to the [Create a Google Workspace provider](./create-gws-provider.md) documentation.
|
||||
- For instructions on configuring your Google Workspace organization in prepation for creating a Google Workspace provider, refer to the [Configure Google Workspace](./configure-gws.mdx) documentation.
|
||||
- For instructions on creating a Google Workspace provider, refer to the [Create a Google Workspace provider](./create-gws-provider.mdx) documentation.
|
||||
|
||||
## Discovery
|
||||
|
||||
@@ -8,13 +8,13 @@ import DocCardList from "@theme/DocCardList";
|
||||
|
||||
A provider is an authentication method, a service that is used by authentik to authenticate the user for the associated application. Common providers are OpenID Connect (OIDC)/OAuth2, LDAP, SAML, a generic proxy provider, and others.
|
||||
|
||||
Providers are the "other half" of [applications](../applications/index.md). They typically exist in a 1-to-1 relationship; each application needs a provider and every provider can be used with one application.
|
||||
Providers are the "other half" of [applications](../applications/index.mdx). They typically exist in a 1-to-1 relationship; each application needs a provider and every provider can be used with one application.
|
||||
|
||||
You can create a new provider in the Admin interface, or you can use the [**New Application** option](../applications/manage_apps.mdx#create-an-application-and-provider-pair) to create a new application and its provider at the same time.
|
||||
|
||||
Applications can use additional providers to augment the functionality of the main provider. For more information, see [Backchannel providers](../applications/manage_apps.mdx#backchannel-providers).
|
||||
|
||||
When you create certain types of providers, you need to select specific [flows](../flows-stages/flow/index.md) to apply to users who access authentik via the provider. To learn more, refer to our [default flow documentation](../flows-stages/flow/default-flows.md).
|
||||
When you create certain types of providers, you need to select specific [flows](../flows-stages/flow/index.mdx) to apply to users who access authentik via the provider. To learn more, refer to our [default flow documentation](../flows-stages/flow/default-flows.mdx).
|
||||
|
||||
You can also create a SAML provider by uploading an SP metadata XML file that contains the service provider's configuration data. SAML metadata is used to share configuration information between the Identity Provider (IdP) and the Service Provider (SP). An SP metadata XML file typically contains the SP certificate, the entity ID, the Assertion Consumer Service URL (ACS URL), and a logout URL (SingleLogoutService).
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ The `default-authentication-flow` validates MFA by default. Duo, TOTP, and stati
|
||||
|
||||
If you plan to use only dedicated service accounts to bind to LDAP, or only use LDAP supported MFA authenticators, then you can use the default authentication flow and skip this section and continue with the [Create an LDAP application and provider](#create-an-ldap-application-and-provider) section.
|
||||
|
||||
Refer to [Code-Based MFA support](./index.md#code-based-mfa-support) for more information on LDAP and MFA.
|
||||
Refer to [Code-Based MFA support](./index.mdx#code-based-mfa-support) for more information on LDAP and MFA.
|
||||
|
||||
### Create custom stages
|
||||
|
||||
@@ -121,7 +121,7 @@ The LDAP provider requires the deployment of an LDAP [Outpost](../../outposts/in
|
||||
2. Navigate to **Applications** > **Outposts**, click **New Outpost** and set the following required configurations:
|
||||
- Provide a **Name** for the outpost (e.g. `LDAP Outpost').
|
||||
- Set the **Type** as `LDAP`.
|
||||
- Set **Integration** to match your deployment method or manually deploy an outpost via [Docker-Compose](../../outposts/manual-deploy-docker-compose.md) or [Kubernetes](../../outposts/manual-deploy-kubernetes.md). For more information, refer to the [Outpost documentation](../../outposts/index.mdx).
|
||||
- Set **Integration** to match your deployment method or manually deploy an outpost via [Docker-Compose](../../outposts/manual-deploy-docker-compose.mdx) or [Kubernetes](../../outposts/manual-deploy-kubernetes.mdx). For more information, refer to the [Outpost documentation](../../outposts/index.mdx).
|
||||
- Under **Applications**, select the LDAP application created in the previous section.
|
||||
- Under **Advanced settings**, set the required outpost configurations. For more information, refer to [Outpost Configuration](../../outposts/index.mdx#configuration)
|
||||
|
||||
@@ -164,10 +164,10 @@ ldapsearch \
|
||||
'(objectClass=user)'
|
||||
```
|
||||
|
||||
This example query will return all users and log the first successful attempt in an event in **Events** > **Logs**. Subsequent successful logins from the same user are not logged by default, as they are cached in the outpost. For more details see [Bind modes](./index.md#bind-modes).
|
||||
This example query will return all users and log the first successful attempt in an event in **Events** > **Logs**. Subsequent successful logins from the same user are not logged by default, as they are cached in the outpost. For more details see [Bind modes](./index.mdx#bind-modes).
|
||||
|
||||
:::warning LDAPS
|
||||
In production it is recommended to use LDAPS, which requires `ldaps://` as the protocol, and port number `636` rather than `389`. See [LDAPS](./index.md#ldaps-via-ssl-or-starttls) for more information.
|
||||
In production it is recommended to use LDAPS, which requires `ldaps://` as the protocol, and port number `636` rather than `389`. See [LDAPS](./index.mdx#ldaps-via-ssl-or-starttls) for more information.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
@@ -179,10 +179,10 @@ To search the LDAP directory using the previously created `ldapservice` service
|
||||
dsquery * -s <LDAP outpost IP address> -u "cn=ldapservice,ou=users,DC=ldap,DC=goauthentik,DC=io" -p <ldapuserpassword> -b "DC=ldap,DC=goauthentik,DC=io" -filter "(objectClass=user)"
|
||||
```
|
||||
|
||||
This example query will return all users and log the first successful attempt in an event in **Events** > **Logs**. Subsequent successful logins from the same user are not logged by default, as they are cached in the outpost. For more details see [Bind modes](./index.md#bind-modes).
|
||||
This example query will return all users and log the first successful attempt in an event in **Events** > **Logs**. Subsequent successful logins from the same user are not logged by default, as they are cached in the outpost. For more details see [Bind modes](./index.mdx#bind-modes).
|
||||
|
||||
:::warning LDAPS
|
||||
In production it is recommended to use LDAPS, which requires `ldaps://` as the protocol, and port number `636` rather than `389`. See [LDAPS](./index.md#ldaps-via-ssl-or-starttls) for more information.
|
||||
In production it is recommended to use LDAPS, which requires `ldaps://` as the protocol, and port number `636` rather than `389`. See [LDAPS](./index.mdx#ldaps-via-ssl-or-starttls) for more information.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
||||
@@ -86,12 +86,12 @@ The **Bind Flow** determines the flow used for binding/authenticating users, and
|
||||
|
||||
The following flow stages are supported by the LDAP provider:
|
||||
|
||||
- [Identification stage](../../flows-stages/stages/identification/index.md)
|
||||
- [Password stage](../../flows-stages/stages/password/index.md)
|
||||
- [Authenticator validation stage](../../flows-stages/stages/authenticator_validate/index.md)
|
||||
- [User Logout stage](../../flows-stages/stages/user_logout/index.md)
|
||||
- [User Login stage](../../flows-stages/stages/user_login/index.md)
|
||||
- [Deny stage](../../flows-stages/stages/deny/index.md)
|
||||
- [Identification stage](../../flows-stages/stages/identification/index.mdx)
|
||||
- [Password stage](../../flows-stages/stages/password/index.mdx)
|
||||
- [Authenticator validation stage](../../flows-stages/stages/authenticator_validate/index.mdx)
|
||||
- [User Logout stage](../../flows-stages/stages/user_logout/index.mdx)
|
||||
- [User Login stage](../../flows-stages/stages/user_login/index.mdx)
|
||||
- [Deny stage](../../flows-stages/stages/deny/index.mdx)
|
||||
|
||||
### Bind modes
|
||||
|
||||
@@ -109,7 +109,7 @@ This mode uses the same logic as direct bind, however the result is cached for t
|
||||
|
||||
Any user that is authorized to access the LDAP provider's application can search the LDAP directory. Without explicit permissions to do broader searches, a user's search request will return information about themselves, including user info, group info, and group membership.
|
||||
|
||||
[Users](../../../users-sources/user/index.mdx) and [roles](../../../users-sources/roles/index.md) can be assigned the permission `Search full LDAP directory` to allow them to search the full LDAP directory and retrieve information about all users in the authentik instance.
|
||||
[Users](../../../users-sources/user/index.mdx) and [roles](../../../users-sources/roles/index.mdx) can be assigned the permission `Search full LDAP directory` to allow them to search the full LDAP directory and retrieve information about all users in the authentik instance.
|
||||
|
||||
:::info
|
||||
Up to authentik version 2024.8 this was managed using the LDAP provider's **Search group** setting, where users could be added to a group to grant them this permission. With authentik 2024.8 this is automatically migrated to the `Search full LDAP directory` permission, which can be assigned more flexibly.
|
||||
@@ -135,7 +135,7 @@ Authenticator validation currently only supports DUO, TOTP and static authentica
|
||||
|
||||
The LDAP provider supports code-based MFA.
|
||||
|
||||
Code-based authenticators are only supported when the **Code-based MFA Support** setting is enabled on the provider and the configured **Bind Flow** includes a [Authenticator Validation stage](../../flows-stages/stages/authenticator_validate/index.md).
|
||||
Code-based authenticators are only supported when the **Code-based MFA Support** setting is enabled on the provider and the configured **Bind Flow** includes a [Authenticator Validation stage](../../flows-stages/stages/authenticator_validate/index.mdx).
|
||||
|
||||
When enabled, all users that bind to the LDAP provider should have a supported authenticator configured, as otherwise a password might be incorrectly rejected if it contains a semicolon.
|
||||
|
||||
@@ -9,7 +9,7 @@ The device code flow is also known as _device flow_ or _device authorization gra
|
||||
|
||||
### Requirements
|
||||
|
||||
This device flow is only possible if the active [brand](../../../customize/branding/index.md) has a device code flow configured. This flow is run _after_ the user logs in, and before the user authenticates.
|
||||
This device flow is only possible if the active [brand](../../../customize/branding/index.mdx) has a device code flow configured. This flow is run _after_ the user logs in, and before the user authenticates.
|
||||
|
||||
authentik does not include a default flow for this use case, so it is necessary to create a new one with a **Designation** of `Stage Configuration`.
|
||||
|
||||
@@ -10,7 +10,7 @@ sidebar_position: 4
|
||||
|
||||
OAuth2/OIDC logout is a security feature defined in the OpenID Connect specification. It allows an OIDC Provider (OP), such as authentik, to notify Relying Parties (RPs) when a user session ends. This ensures that all associated applications can properly terminate the user's session.
|
||||
|
||||
For more information about single logout across all providers, see the [Single Logout (SLO) Overview](../single-logout/index.md).
|
||||
For more information about single logout across all providers, see the [Single Logout (SLO) Overview](../single-logout/index.mdx).
|
||||
|
||||
:::warning
|
||||
Your OAuth application (Relying Party) must explicitly support OpenID Connect front-channel logout or back-channel logout to properly handle logout requests. Not all OAuth applications support these features, so compatibility should be verified.
|
||||
@@ -62,7 +62,7 @@ https://api.service.com/logout
|
||||
|
||||
OIDC Relying Parties can initiate logout by redirecting a user to authentik's `end_session` endpoint. By default, only that application's session is ended while the authentik session remains active and the user stays logged in to other applications.
|
||||
|
||||
For instructions on how to trigger full Single Logout when a user logs out from an application, see [Enable full Single Logout for RP-initiated logout](../single-logout/index.md#enable-full-single-logout-for-rp-initiated-logout).
|
||||
For instructions on how to trigger full Single Logout when a user logs out from an application, see [Enable full Single Logout for RP-initiated logout](../single-logout/index.mdx#enable-full-single-logout-for-rp-initiated-logout).
|
||||
|
||||
## How OpenID Connect single logout works
|
||||
|
||||
@@ -118,8 +118,8 @@ Front-channel logout only works for user-initiated logouts through a logout flow
|
||||
|
||||
## Resources
|
||||
|
||||
- [Single Logout (SLO) Overview](../single-logout/index.md)
|
||||
- [User Logout Stage](../../flows-stages/stages/user_logout/index.md)
|
||||
- [Single Logout (SLO) Overview](../single-logout/index.mdx)
|
||||
- [User Logout Stage](../../flows-stages/stages/user_logout/index.mdx)
|
||||
- [OAuth2 Provider Configuration](./index.mdx)
|
||||
- [OpenID Connect Back-Channel Logout 1.0 Specification](https://openid.net/specs/openid-connect-backchannel-1_0.html)
|
||||
- [OpenID Connect Front-Channel Logout 1.0 Specification](https://openid.net/specs/openid-connect-frontchannel-1_0.html)
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: OAuth 2.0 provider
|
||||
---
|
||||
|
||||
In authentik, you can [create](./create-oauth2-provider.md) an [OAuth 2.0](https://oauth.net/2/) provider to authenticate users to an associated application. The provider supports both OAuth 2.0 and OpenID Connect (OIDC).
|
||||
In authentik, you can [create](./create-oauth2-provider.mdx) an [OAuth 2.0](https://oauth.net/2/) provider to authenticate users to an associated application. The provider supports both OAuth 2.0 and OpenID Connect (OIDC).
|
||||
|
||||
## authentik and OAuth 2.0
|
||||
|
||||
@@ -11,11 +11,11 @@ Before taking a [closer look at OAuth 2.0 and OIDC](#about-oauth-20-and-oidc), i
|
||||
authentik can act as either an OpenID Provider (OP) or a Relying Party (RP):
|
||||
|
||||
- To use authentik as an OP, create an OAuth 2.0 provider and associate it with an application.
|
||||
- To use authentik as an RP, configure an OAuth or OIDC [source](../../../users-sources/sources/index.md).
|
||||
- To use authentik as an RP, configure an OAuth or OIDC [source](../../../users-sources/sources/index.mdx).
|
||||
|
||||
authentik can act as both an OP and an RP in the same deployment.
|
||||
|
||||
authentik supports common OAuth 2.0 and OIDC flows and grant types, including authorization code, client credentials, implicit, hybrid, device code, refresh token, and token exchange. authentik follows the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) and supports PKCE, [GitHub compatibility](./github-compatibility.md), and scope mappings.
|
||||
authentik supports common OAuth 2.0 and OIDC flows and grant types, including authorization code, client credentials, implicit, hybrid, device code, refresh token, and token exchange. authentik follows the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) and supports PKCE, [GitHub compatibility](./github-compatibility.mdx), and scope mappings.
|
||||
|
||||
The authentik OAuth 2.0 provider supports standard OAuth 2.0 security features, including secure credential storage, configurable signing and encryption, configurable token expiration times, and automatic refresh token rotation.
|
||||
|
||||
@@ -122,7 +122,7 @@ authentik supports the following general OAuth 2.0 and OpenID Connect flows:
|
||||
|
||||
The [refresh token](#refresh-token-grant) grant allows a client to obtain new access tokens without repeating the original authorization flow.
|
||||
|
||||
You can define which grant types are available for your OAuth2 provider when you [create and configure the provider](./create-oauth2-provider.md). By default, all types are selected.
|
||||
You can define which grant types are available for your OAuth2 provider when you [create and configure the provider](./create-oauth2-provider.mdx). By default, all types are selected.
|
||||
|
||||
### 1. Web-based application authorization
|
||||
|
||||
@@ -172,7 +172,7 @@ For more information, see [Machine-to-machine authentication](./machine_to_machi
|
||||
|
||||
The device code flow is intended for devices that have limited input capabilities or do not have a suitable browser. For example, a television application can display a code that the user enters on a website using a phone or computer. After the user authenticates, the television application receives authorization.
|
||||
|
||||
For more information, see [Device code flow](./device_code.md).
|
||||
For more information, see [Device code flow](./device_code.mdx).
|
||||
|
||||
### 4. Token exchange
|
||||
|
||||
@@ -180,7 +180,7 @@ The token exchange grant allows a client to exchange an existing token for a new
|
||||
|
||||
With delegation, also known as on-behalf-of (OBO) token exchange, the issued token identifies both the user and the authentik Actor acting on the user's behalf.
|
||||
|
||||
For configuration instructions and information about supported parameters, see [Token exchange](./token_exchange.md).
|
||||
For configuration instructions and information about supported parameters, see [Token exchange](./token_exchange.mdx).
|
||||
|
||||
:::info
|
||||
Delegation and on-behalf-of token exchange are available in authentik 2026.8 and later.
|
||||
@@ -192,7 +192,7 @@ The refresh token grant allows a client to obtain a new access token without req
|
||||
|
||||
## Scope mappings
|
||||
|
||||
Scopes can be configured using scope mappings, which are a type of [property mapping](../property-mappings/index.md#scope-mappings-with-oauth2).
|
||||
Scopes can be configured using scope mappings, which are a type of [property mapping](../property-mappings/index.mdx#scope-mappings-with-oauth2).
|
||||
|
||||
## Scope authorization
|
||||
|
||||
|
||||
@@ -9,6 +9,6 @@ The [WebFinger protocol](https://webfinger.net/) allows for the discovery of inf
|
||||
|
||||
## authentik WebFinger support
|
||||
|
||||
authentik provides a WebFinger endpoint when the **Default application** setting uses an OIDC provider. Instructions on how to set a **Default application** can be found in the [authentik Branding documentation](../../../customize/branding/index.md#external-user-settings).
|
||||
authentik provides a WebFinger endpoint when the **Default application** setting uses an OIDC provider. Instructions on how to set a **Default application** can be found in the [authentik Branding documentation](../../../customize/branding/index.mdx#external-user-settings).
|
||||
|
||||
The WebFinger endpoint is available at: `https://authentik.company/.well-known/webfinger` (where authentik.company is the FQDN of your authentik instance)
|
||||
|
||||
@@ -12,11 +12,11 @@ import Functions from "../../../expressions/reference/_functions.mdx";
|
||||
|
||||
## Variables
|
||||
|
||||
import Objects from "../../../expressions/reference/_objects.md";
|
||||
import Objects from "../../../expressions/reference/_objects.mdx";
|
||||
|
||||
<Objects />
|
||||
|
||||
import User from "../../../expressions/reference/_user.md";
|
||||
import User from "../../../expressions/reference/_user.mdx";
|
||||
|
||||
<User />
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Create a proxy provider
|
||||
---
|
||||
|
||||
For an overview of how proxy providers work, see the [proxy provider](./index.md) documentation.
|
||||
For an overview of how proxy providers work, see the [proxy provider](./index.mdx) documentation.
|
||||
|
||||
## Workflow to create a proxy provider
|
||||
|
||||
@@ -11,7 +11,7 @@ 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.
|
||||
Refer to the [create a proxy provider](./create-proxy-provider.mdx) documentation for setup instructions.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
@@ -77,7 +77,7 @@ additionalHeaders:
|
||||
X-test-header: test-value
|
||||
```
|
||||
|
||||
For dynamic headers, see the [custom headers](./custom_headers.md) documentation.
|
||||
For dynamic headers, see the [custom headers](./custom_headers.mdx) documentation.
|
||||
|
||||
## HTTPS
|
||||
|
||||
@@ -5,8 +5,8 @@ title: Caddy
|
||||
import TabItem from "@theme/TabItem";
|
||||
import Tabs from "@theme/Tabs";
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
import CaddyStandalone from "./_caddy_standalone.md";
|
||||
import Placeholders from "./__placeholders.mdx";
|
||||
import CaddyStandalone from "./_caddy_standalone.mdx";
|
||||
|
||||
The configuration template shown below applies to both single-application and domain-level forward auth.
|
||||
|
||||
|
||||
@@ -5,8 +5,8 @@ title: Envoy
|
||||
import TabItem from "@theme/TabItem";
|
||||
import Tabs from "@theme/Tabs";
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
import EnvoyIstio from "./_envoy_istio.md";
|
||||
import Placeholders from "./__placeholders.mdx";
|
||||
import EnvoyIstio from "./_envoy_istio.mdx";
|
||||
|
||||
The configuration template shown below applies to both single-application and domain-level forward auth.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ import Tabs from "@theme/Tabs";
|
||||
|
||||
The configuration templates shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
import Placeholders from "./__placeholders.mdx";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
@@ -18,21 +18,21 @@ import Placeholders from "./__placeholders.md";
|
||||
]}>
|
||||
<TabItem value="standalone-nginx">
|
||||
|
||||
import NginxStandalone from "./_nginx_standalone.md";
|
||||
import NginxStandalone from "./_nginx_standalone.mdx";
|
||||
|
||||
<NginxStandalone />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ingress">
|
||||
|
||||
import NginxIngress from "./_nginx_ingress.md";
|
||||
import NginxIngress from "./_nginx_ingress.mdx";
|
||||
|
||||
<NginxIngress />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="proxy-manager">
|
||||
|
||||
import NginxProxyManager from "./_nginx_proxy_manager.md";
|
||||
import NginxProxyManager from "./_nginx_proxy_manager.mdx";
|
||||
|
||||
<NginxProxyManager />
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user