过于详细！终于搞懂SSO里面的SAML和OIDC讲的什么了

Posted 2023-04-24

参考技术A

在了解SSO是什么之前，我们需要搞清楚两个概念： Authentication & Authorization。

Authentication(又被称为AuthN，身份验证)，它指的是 the process of verifying that "you are who you say you are"，也就是说这个过程是为了证明你是你。通常来说有这么几个方式：

Authorization(又被称为AuthZ，权限验证)，他指的是 the process of verifying that "you are permitted to do what you are trying to do"，也就是说这个过程是为了证明你是否拥有做这件事的权限，比如修改某个表格等等，如果没有权限的话通常会返回 403 错误码。

在 SSO 出现之前，用户在不同的系统登录就需要在不同的系统注册多个账号，然后需要自己记住多个用户名和密码，而如果这些系统是同一个平台的话，其实该平台还需要维护多套几乎一模一样的登录系统，给用户和平台都带来了负担。

而 SSO 就是一种authentication scheme（身份验证方案），SSO 允许用户使用同一个账户登录不同的系统，很好地解决了上述的问题。它不但可以实现单一平台的登录，假如某个平台之外的系统是信任该平台的，那么外部系统也可以集成这个平台的 SSO， 比如现在的大多数网站都提供了 Google 账号登录的功能。

要实现 SSO，首先需要你正在开发的系统信任这个第三方登录系统所提供的用户信息，然后你需要按照一定的标准和协议去与其对接，接下来我们会介绍两个比较常用的 SSO 协议 -- SAML 2.0 和 OIDC。

SAML 2.0是什么

SAML 是 Security Assertion Markup Language 的简称，是一种基于XML的开放标准协议，用于在身份提供者（Identity Provider简称IDP）和服务提供商（Service Provider简称SP）之间交换认证和授权数据。

SAML 2.0是该协议的最新版本，于2005年被结构化信息标准组织（OASIS）批准实行。

流程

SAML flow

SAML Assertion

那么这个 SAML Assertion 又是个啥呢？

首先用户为什么可以访问SP上的资源呢？肯定是因为其实SP也有一份用户的资料，这个资料里面可能有用户的账户信息，权限等等，但是现在用户的信息是由IDP提供的，所以现在需要做的就是讲两份用户信息映射起来，好让SP知道IDP提供的用户到底是哪一个。

而这个映射的约定，就是SP和IDP进行集成的时候的一个配置，这个配置叫做 metadata。这个配置有两份，两边各一份，里面约定了应该怎么去映射用户信息，签名的证书等。IDP和SP会通过别的方式去交换这两份 metadata。

所以其实 SAML Assertion 里面包含了用户的唯一标识，能够证明该用户是谁。在SP拿到这份信息后就会按照一些规则去验证里面的信息是否是合法的用户。

那么问题来了，如果中间人知道了我们之间的规则随便塞了一份信息进来咋办？所以其实 SAML Assertion 里面除了用户信息其实还有IDP的签名，只有SP先解析了里面的签名确认无误之后才会信任这份信息。

知道了 SAML Assertion 是个啥以后，我们还需要弄清楚它是怎么发送出去的。要弄清楚它们是怎么发送出去的我们需要知道一个东西叫做 binding method。

SAML 2.0 有许多不同的 binding，它们其实就是 SAML Assertion 的交互方式：

其中现在用的比较多的是前三种，它们都是基于HTTP协议来实现的。

metadata

上面提到过 metadata 是为了让IDP和SP明白彼此交流的信息，并且有一些安全考虑，里面主要的信息有：

其中有一个字段 md:KeyDescriptor 在SP中有一个 encryption，在SP和IDP进行通信建立信任的时候，IDP就会拿到SP加密的key，在用户登录成功后，IDP就会用这个key加密 SAML Assertion，SP拿到后通过自己的私钥进行解密。另一个叫 signing 的字段会被用来解析对方的签名，用来辨别这个 Assertion 是不是我想要的人发过来的。

OIDC是什么

OpenID Connect(OIDC) 是建立在 OAuth 2.0 协议之上的一个简单的身份层，它允许计算客户端根据授权服务器执行的认证，以 JSON 作为数据格式，验证终端用户的身份。它是 OpenID 的第三代规范，前面分别有 OpenID 和 OpenID 2.0。它在OAuth 2.0 的基础上增加了 ID Token 来解决第三方客户端标识用户身份认证的问题。

它的结构如图所示：

image-20200601085202978

从它的结构图中可以看出，除了核心实现外，OIDC 还提供了一系列可选的扩展功能。比如：

由于图片距今已经有些年限了，其实现在OIDC还提供了许多可选的扩展，具体可到官网查看。

流程

由于 OIDC 是基于 OAuth 2.0 的，所以 OIDC 也拥有多种 flow。由于篇幅所限我这里会相对详细地解释 Authorization Code Flow，在开始前我们需要弄清楚几个名称：

Authorization Code flow

Implicit Flow 是在 OP redirect EU 到 RP 的时候会带上 ID Token 和 Access Token(如果必要) 而不是 Authorization Code，同时在发送请求的时候也会有一些不同，需要带上一些别的参数，这里就不细讲了，总的流程是差不多的，详情可以查看这里

Hybrid Flow 可以理解为上面两个 flow 的结合，OP redirect EU 到 RP 的时候会带上 Authorization Code，同时根据发送请求时候 Response Type 参数的不同还会带上一些别的参数，具体流程可以参考这里

SAML简介

1、什么是SAML：

SAML是Web浏览器用来通过安全令牌启用单点登录（SSO）的标准协议

2、优点：

跨多个应用程序管理用户身份和授权。

3、单点登录（SSO）是什么：

它使用户仅使用一组凭据（用户名和密码）登录一次，就可以安全地对多个应用程序和网站进行身份验证。

4、SSO如何工作？

使用SSO，用户尝试访问的应用程序或网站依赖于受信任的第三方来验证用户的身份。