技能介绍

要解决的问题

给 SaaS 或 AI 应用加认证和授权，往往意味着把协议栈、租户模型、权限粒度和多端接入全部自己搭一遍。团队要么写自建方案，在 OIDC、OAuth 2.1、会话、用户目录之间反复踩坑；要么引入托管身份服务，结果在费用、厂商锁定和合规边界上长期受限。应用越靠近多租户、企业客户和内部协作，认证授权就越容易从功能变成架构瓶颈。

这个技能如何工作

Logto 的定位是替代 Auth0 与 Cognito，而不是单纯封一层登录页。它围绕 OIDC 和 OAuth 2.1 组织身份、会话与授权流程，并把多租户、企业 SSO、RBAC 等常见需求放进同一套基础设施里。对工程师来说，技能的价值是把“谁能登录、能访问哪个租户、能调用哪些资源”拆成可维护的工程对象，再通过 30 多个框架的 SDK 落到业务代码中。

使用时可以先梳理应用的认证主体：独立用户、企业租户、第三方身份源、后端 API 与前端客户端。接着把权限模型映射到 RBAC 的 role、resource 和 policy，避免把授权逻辑散落在业务分支里。企业 SSO 适合放在多租户边界内管理，让不同组织的登录入口、用户目录和访问策略保持隔离。SDK 则承担客户端接入、会话刷新和 API 调用所需的协议细节。

适用边界与注意点

它适合需要统一身份、多客户端接入、企业客户接入和明确角色边界的项目。如果系统已经依赖某家托管身份服务且迁移成本很高，就要先评估会话、密钥、组织目录和现有 API 权限的兼容情况。部署环境也要提前确认：Docker Compose 路径依赖 Docker Desktop，Node.js 路径依赖外部 PostgreSQL。这些资料不提供高可用、备份、网络隔离或合规认证的现成保证，上线前仍需结合基础设施与安全评审完成部署和配置。