authentik：Application、Provider 与 Flow 如何组成身份入口
登录页出现了，协议对象仍可能没有接好
authentik 不是“另一个 Keycloak 皮肤”。Application 是用户看到的应用入口，Provider 定义 OIDC、SAML、LDAP、Proxy 等协议，Flow 组织认证与授权阶段，Policy 决定绑定条件；Proxy、LDAP、RADIUS 与 RAC Provider 还需要 Outpost 承载协议逻辑。把这些对象混成一个“client”，会让登录成功、token 签发、应用访问和边缘代理之间的责任无法解释。
本地实验先确定问题范围。只验证 JWT 解析不必启动完整身份平台；需要验证 authentik 的 Flow、Policy、Application/Provider 或 Outpost 时，才值得承担 PostgreSQL、worker、签名密钥和管理入口的成本。
从官方 Compose 建立可重建输入
官方 Docker Compose 安装文档将此路径定位为测试与小规模生产入口，并要求 Compose v2、至少 2 核与 2 GB 内存。下载的 Compose 会静态引用当时的版本；升级不是只改标签，而是重新下载对应文件、审查差异后更新整套服务。
curl -fsSLo compose.yml https://docs.goauthentik.io/compose.yml
printf 'PG_PASS=%s\n' "$(openssl rand -base64 36 | tr -d '\n')" >> .env
printf 'AUTHENTIK_SECRET_KEY=%s\n' "$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose -f compose.yml pull
docker compose -f compose.yml up -d.env 不进入 Git。首次从 http://localhost:9000 为 akadmin 建立密码。默认 Compose 会把 Docker socket 挂给 worker，用于自动创建和管理 Outpost；这是宿主机控制面权限。当前实验不需要自动 Outpost 时，应删除挂载。需要 Outpost 但不接受 socket 风险时，按官方 手工 Compose 部署单独运行，并给它范围受限的服务账号 token。
Application 与 Provider 要分别验明
从 Applications 进入 New Provider，官方当前向导可以一起创建 Application 与 OAuth2/OIDC Provider。为测试应用设置独立 slug、精确 redirect URI、Authorization Code + PKCE 和非对称 Signing Key。没有适合 JWKS 的签名 key，资源服务就无法按 kid 找到公钥。
issuer: http://localhost:9000/application/o/te-web/
discovery: http://localhost:9000/application/o/te-web/.well-known/openid-configuration
jwks: http://localhost:9000/application/o/te-web/jwks/
token: http://localhost:9000/application/o/token/不要从 URL 外形猜 issuer。请求 discovery，记录它返回的 issuer、jwks_uri 与 token_endpoint，再检查 JWT 的 iss、kid、aud 和 exp：
curl -fsS http://localhost:9000/application/o/te-web/.well-known/openid-configuration | jq '{issuer,jwks_uri,token_endpoint}'
curl -fsS http://localhost:9000/application/o/te-web/jwks/ | jq '.keys[] | {kid,kty,alg}'资源服务应信任 discovery 返回的 issuer。若浏览器用 localhost、容器却用内部 DNS，先选定双方都可解析的外部身份，再配置反向代理与内部访问；关闭 issuer 校验只会把配置错误变成安全缺口。
Flow、Policy 与 Outpost 各有边界
Flow 决定认证、授权、注册或恢复过程中执行哪些 Stage；Policy 绑定在 Flow、Application 或其他对象上，决定某个主体能否继续。调试时先看实际绑定与评估结果，不要把“用户存在”当作必然能进入 Application。
Outpost 是可独立部署的 authentik 组件。官方说明 Proxy、LDAP、RADIUS 与 RAC Provider 需要它；创建 Outpost 会生成服务账号和 token，只授予读取所绑定 Application/Provider 配置所需的权限。Outpost 通过 API 与 WebSocket 接收配置和报告健康状态。核心实例与 Outpost 升级必须保持同版本，不能把旧边缘组件留在外面静默漂移。
OIDC Provider 本身由核心服务处理，通常不需要为了 OIDC 再建一个 Proxy Outpost。只有应用要经过 authentik Proxy、暴露 LDAP/RADIUS 或使用 RAC 时，才引入相应 Outpost，并分别验证网络、token、证书和应用绑定。
数据、密钥与退出
PostgreSQL 保存用户、Application、Provider、Flow、Policy 与审计对象；media、证书、签名材料和 Outpost token 也有独立生命周期。删除 server 容器不会删除这些状态，docker compose down -v 又会把整个本地身份环境清空。运行前先确认 Compose project 只属于当前实验。
测试用户必须使用虚构资料。PG_PASS、AUTHENTIK_SECRET_KEY、client secret、Outpost token、authorization code、JWT、Cookie 与签名私钥不进入仓库、日志和截图。Blueprint 或数据库备份也可能携带身份属性和 secret，不能因为是“配置导出”就默认可提交。
本地退出要停止并删除 Compose project、测试 Application/Provider、用户、Flow 绑定、Outpost、服务账号 token、反向代理路由和 DNS。若准备转入共享或生产，进入 authentik 身份平台继续完成外部数据库、备份恢复、HA、升级与密钥轮换；本地联调成功不能代替这些验收。