Logto 重定向式登录Redirect-based Sign-in机制解析OIDC 认证流程与多应用单点登录实践【免费下载链接】logto Authentication and authorization infrastructure for SaaS and AI apps, built on OIDC and OAuth 2.1 with multi-tenancy, SSO, and RBAC.项目地址: https://gitcode.com/GitHub_Trending/lo/logto重定向式登录是 Logto 中所有 Web 应用、SPA 与原生应用接入认证的标准方式应用将用户重定向到 Logto 托管的登录页用户完成认证后再被重定向回应用。本文基于 packages/console/src/assets/docs/fragments/_regarding-redirect-based-sign-in.md 这一随各接入指南复用的说明片段深入讲解其背后的 OIDC 协议原理、Logto 的安全保障机制以及多个应用共用同一身份提供者即可自动完成登录的单点登录SSO能力并结合仓库源码与真实接入示例给出可落地的配置方法。什么是重定向式登录从一次简单的两步跳转说起在深入细节之前Logto 官方文档先用一张极简的流程图概括了终端用户侧的登录体验见 packages/console/src/assets/docs/fragments/_experience-overview.mdx展开来看完整的重定向式登录包含三个步骤你的应用调用 SDK 的 sign-in 方法例如logtoClient.signIn(redirectUri)。用户被重定向到 Logto 的登录页面对于原生应用Native App此时会打开系统浏览器System Browser而非应用内嵌 WebView。用户完成登录后被重定向回你的应用——回跳地址即你在 Logto 应用配置中登记的redirect URI。这就是重定向式登录名称的由来认证的完整生命周期携带凭证、展示登录页、签发令牌都发生在 Logto 这一侧应用本身不接触用户的密码或验证码只负责把人送过去、把人接回来。Logto 在该片段中同时强调了两条关键事实这一认证过程遵循OpenID Connect (OIDC)协议且 Logto 会强制执行严格的安全措施来保护用户登录如果你有多个应用可以共用同一个身份提供者即 Logto。用户在一个应用登录后再访问另一个应用时Logto 会自动完成登录过程。这两点正是重定向式登录区别于应用内嵌登录页的核心价值所在下面分别展开。为什么是基于 OIDC协议约束与安全强制片段明确指出该认证过程遵循 OpenID Connect (OIDC) 协议这为整个登录链路提供了协议级的规范性保障。在 Logto 的 core 包中OIDC 层基于oidc-provider实现所有应用OIDC 术语中的 Client的元数据都由 Logto 侧的适配器统一管理。在 packages/core/src/oidc/adapter.ts 中可以看到每个应用都会登记一组 OIDC 标准的客户端元数据其中最核心的两项正是重定向式登录的落点redirect_uris用户登录成功后允许回跳的地址集合必须与应用在 Logto Console 中配置的 redirect URI 精确匹配post_logout_redirect_uris用户退出登录RP-Initiated Logout后允许回跳的地址集合。代码中甚至为 Admin Console、Demo AppLive Preview、Account Center 等内置应用自动追加这两类 URI见transpileMetadata与buildDemoAppClientMetadata等函数说明 Logto 在内部也严格遵循同一套 OIDC 回跳约束而非绕过协议自造流程。从协议层面看严格的安全措施具体体现在以下几个方面回跳地址白名单校验OIDC 协议要求授权服务器仅向已登记的回跳地址发出授权码或 ID TokenLogto 对每个请求按redirect_uris逐一比对防止开放重定向Open Redirect攻击授权码与令牌绑定登录完成后应用拿到的授权码只能与发起登录时的客户端client_id及回跳地址配套使用无法被第三方截取重放会话由身份提供者托管密码、验证码等敏感凭证只出现在 Logto 的登录体验Sign-in Experience页面中应用侧 SDK 全程不接触缩小了凭证泄露面。因此遵循 OIDC 并不是一句口号而是 Logto 以协议为骨架、以 URI 白名单和令牌绑定为安全边界的实现事实。从源码结构看packages/core/src/oidc/目录下完整的adapter.ts、adapter.test.ts等文件正是这一协议层的落地载体。多个应用共享同一身份提供者自动登录与单点登录片段中的第二条要点非常关键多应用可以共用同一个 Logto 作为身份提供者用户在一个应用登录后访问另一个应用时无需再次登录。其原理正是重定向式登录 OIDC 会话的自然结果应用 A 将用户重定向到 Logto 登录页用户在 Logto 完成认证后Logto 建立该用户的 IdP 会话登录态 Cookie并向应用 A 签发 ID Token / 授权码用户随后访问应用 B应用 B 同样将用户重定向到 Logto由于 Logto 侧已有有效会话Logto 不再要求用户重新输入凭证而是直接完成认证流程并签发新的令牌将用户带回应用 B。从 OIDC 协议机制可以推断这一自动完成登录行为的本质是授权请求Authorization Request在身份提供者一侧命中已建立的认证会话从而省略了凭证收集环节。只要多个应用配置在同一个 Logto 租户下、使用同一个 Logto 实例作为端点endpoint即可天然获得这种跨应用的免登录体验无需在应用之间共享任何会话状态。这一能力与 Logto 的企业 SSO 能力在登录体验层面形成互补在 end-user-flows/sign-in-flow.md 记录的登录流程中可以看到当用户使用企业邮箱登录时登录体验会判断是否由Enterprise SSO 接管Check whether enterprise SSO should take over若是则直接重定向到企业 IdP而 packages/console/src/assets/docs/single-sign-on/ 目录下的 Azure ADSAML等 SSO 接入指南则展示了如何让企业用户通过其组织身份统一认证。换言之多应用共用身份提供者解决的是 Logto 内部多个应用间的免登录问题而企业 SSO 解决的是 Logto 对接外部企业 IdP 的问题两者都建立在认证发生在身份提供者侧、应用侧仅做重定向这一共同前提之上。实战场景一Chrome 扩展中的重定向登录重定向式登录并非只适用于常规 Web 应用在 SPA Chrome 扩展接入指南 中Logto 展示了它在弹出页 Service Worker架构下的完整落地方式。该指南以扩展弹窗中的 Sign in 按钮为例给出如下时序这里有两个值得注意的重定向式登录实现细节第一认证必须由 Service Worker 承担。扩展的 popup 页或 options 页随时可能被关闭而认证过程跨越浏览器与 Logto 两个环境不能在随时会消失的页面中执行后台脚本service worker能保证认证流程被完整处理。第二回跳地址来自 Chrome 内置 API。指南中的 sign-in 与 sign-out 分别使用两个由chrome.identity.getRedirectURL生成的 URIhttps://extension-id.chromiumapp.org/callback——用于登录回跳https://extension-id.chromiumapp.org/——用于退出回跳。这两个 URI 不可被直接访问只用于触发浏览器侧的认证动作本质上是受控的 redirect URI。对应地需要在扩展的manifest.json中声明所需权限{ permissions: [identity, storage], host_permissions: [https://*.logto.app/*] }permissions.identity使用 Chrome Identity API 完成登录与退出permissions.storage存储用户会话host_permissions允许 SDK 与 Logto API 通信若 Logto Cloud 使用自定义域名需改为自己的域名。随后在 Service Worker 中初始化 SDK 并处理消息import LogtoClient from logto/chrome-extension; export const logtoClient new LogtoClient({ endpoint: your-logto-endpoint appId: your-logto-app-id, });chrome.runtime.onMessage.addListener((message, sender, sendResponse) { if (message.action signIn) { const redirectUri chrome.identity.getRedirectURL(/callback); logtoClient.signIn(redirectUri).finally(sendResponse); return true; } if (message.action signOut) { const redirectUri chrome.identity.getRedirectURL(); logtoClient.signOut(redirectUri).finally(sendResponse); return true; } return false; });关键一步把回跳地址登记到 Logto 应用配置。生成上述 URI 之后必须在 Logto Console 的应用设置中登记Redirect URIs登录回跳填入https://extension-id.chromiumapp.org/callbackPost sign-out redirect URIs退出回跳填入https://extension-id.chromiumapp.org/CORS allowed origins跨域白名单填入扩展源chrome-extension://extension-idSDK 将以此 origin 与 Logto API 通信。这与前文提到的redirect_uris/post_logout_redirect_uris客户端元数据一一对应——Logto 只允许向白名单内的地址回跳未登记或拼写不一致都会导致登录/退出流程中断。登录完成后扩展页面即可通过logtoClient.isAuthenticated()与logtoClient.getIdTokenClaims()读取认证状态和用户信息{ sub: ..., email: ..., ... }。实战场景二.NET Core MVC 中的回调路径与重定向 URI在服务端渲染技术栈中重定向式登录同样适用但要注意中间件术语与 Logto 术语的对应关系。.NET Core MVC 登录/退出流程说明 专门澄清了这一最常见的混淆点.NET Core 认证中间件中有两个名称相似但职责不同的概念CallbackPathLogto 登录完成后将用户重定向回来的地址——即 Logto 术语中的redirect URIRedirectUri中间件在 Logto 侧完成必要动作之后将用户最终重定向到的地址——即应用自己的页面地址。两者的差异可以直观地用下面的流程表示登录流程中用户在应用侧的登录入口Sign-in path被重定向到 Logto认证完成后 Logto 回跳到 CallbackPath即 Logto 侧的 redirect URI中间件处理完回调后再把用户送到最终的 RedirectUri应用内部页面。退出流程同理.NET Core 对应提供SignedOutCallbackPath对应 Logto 的 post sign-out redirect URI与用于退出后最终落地的RedirectUri。官方给出的术语对照表如下本文统一术语.NET Core 术语Logto redirect URI登录回跳CallbackPathLogto post sign-out redirect URI退出回跳SignedOutCallbackPathApplication redirect URI应用内最终地址RedirectUri这一对照关系提醒接入者配置时不要把Logto 回跳地址与应用最终落地地址混为一谈——前者必须在 Logto Console 登记后者属于应用内部路由。理解了这层映射.NET Core MVC 应用接入 Logto 重定向式登录时就不会在回跳环节出现 404 或地址不匹配的问题。重定向回跳地址的注册与校验Logto 侧如何落地无论是 Chrome 扩展还是 .NET Core MVC所有重定向式登录都离不开在 Logto 侧登记回跳地址这一步。从源码看Logto 将这一约束落实为 OIDC 客户端的标准元数据字段普通应用在创建/更新时其redirect_uris与post_logout_redirect_uris作为客户端元数据持久化对 Admin Console 这类内置应用packages/core/src/oidc/adapter.ts 中的transpileMetadata会在运行时根据环境变量动态追加{admin/cloud endpoint}/console/callback等回跳地址确保管理控制台即使在动态端点下也能走通重定向登录adapter.test.ts中对应的断言例如校验应用redirect_uris是否包含自定义域名下的/account回调说明这些元数据在测试层面也受到严格约束。这意味着redirect URI 的匹配校验发生在协议层任何未经登记的回跳地址都不会被 Logto 接受。这既是安全的保证也是排错时的首要检查项——当登录完成后没有如约跳回应用时先核对 Logto Console 中登记的地址与代码里实际使用的回跳地址是否完全一致包括协议、域名、端口、路径大小写。小结重定向式登录是 Logto 接入架构的基石其核心要点可归纳为协议规范整个流程遵循 OIDCOpenID Connect Core 1.0Logto 通过回跳地址白名单、令牌绑定与 IdP 侧托管凭证等机制强制执行安全约束多应用免登录多个应用共用同一个 Logto 身份提供者时用户在一个应用完成登录后访问其他应用会被自动完成认证——这是重定向式登录带来的天然单点登录体验配置三件套接入任何应用Web、SPA、Chrome 扩展、.NET Core MVC时都需要正确配置登录回跳地址redirect URI、退出回跳地址post sign-out redirect URI必要时配置跨域白名单并确保与代码中实际使用的地址逐一对应。如需进一步了解 Logto 登录体验的完整行为可继续阅读仓库内的 end-user-flows/sign-in-flow.md登录流程全图、packages/console/src/assets/docs/fragments/_experience-overview.mdx体验总览以及 packages/console/src/assets/docs/guides/ 下各技术栈的具体接入指南。【免费下载链接】logto Authentication and authorization infrastructure for SaaS and AI apps, built on OIDC and OAuth 2.1 with multi-tenancy, SSO, and RBAC.项目地址: https://gitcode.com/GitHub_Trending/lo/logto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
