SAML

1. 还 未登陆 的用户 打开浏览器 访问你的网站（SP），网站 提供服务 但是并 不负责用户认证。
   

2. 于是 SP 向 IDP(LDAP) 发送了一个 SAML 认证请求，同时 SP 将 用户浏览器 重定向到 IDP。
   

3. IDP 在验证完来自 SP 的 请求无误 之后，在浏览器中呈现 登陆表单 让用户填写 用户名 和 密码 进行登陆。
   

4. 一旦用户登陆成功， IDP 会生成一个包含 用户信息（用户名 或者 密码）的 SAML token（SAML token 又称为 SAML Assertion，本质上是 XML 节点）。IDP 向 SP 返回 token，并且将 用户重定向 到 SP (token 的返回是在 重定向步骤 中实现的，下面会详细说明)。
   

5. SP 对拿到的 token 进行验证，并从中解析出 用户信息，例如 用户是谁 以及 用户的权限 有哪些。此时就能够根据这些信息允许用户访问我们网站的内容。
   

当用户在 IDP 登陆成功之后，IDP 需要将用户 再次重定向 到 SP 站点，这一步通常有两个办法：

• HTTP 重定向：这并不推荐，因为 重定向 的 URL 长度 有限制，无法携带更长的信息，比如 SAML Token。
  

• HTTP POST 请求：这个是更常规的做法，当用户登陆完毕之后渲染出一个表单，用户点击后向 SP 提交 POST 请求。又或者可以使用 JavaScript 向 SP 发出一个 POST 请求。
  

如果你的应用是基于 Web，那么以上的方案没有任何问题。但如果你开发的是一个 iOS 或者 Android 的手机应用，那么问题就来了：

1. 用户在 iPhone 上打开应用，此时用户需要通过 IDP 进行认证。
   

2. 应用跳转至 Safari 浏览器，在登陆认证完毕之后，需要通过 HTTP POST 的形式将 token 返回至 手机应用。
   

虽然 POST 的 url 可以 拉起应用，但是 手机应用 无法解析 POST 的内容，我们也就无法读取 SAML Token。

当然还是有办法的，比如在 IDP 授权阶段 不跳转至系统的 Safari 浏览器，在 内嵌 的 Webview 中解决，在想方设法从 Webview 中提取 token，或者利用 代理服务器。

无论如何，SAML 2.0 并 不适用 于当下 跨平台 的场景，这也许与它产生的年代也有关系，它诞生于 2005 年，在那个时刻 HTTP POST 确实是最好的选择方案。

作者：零壹技术栈

链接：https://juejin.cn/post/6844903634094784520

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。