SSO里面的SAML和OIDC到底讲了啥

本文首发于个人博客 https://teobler.com 转载请注明出处

SSO是什么

在了解SSO是什么以前，咱们须要搞清楚两个概念： Authentication & Authorization。

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

• Single-factor - 也就是能够经过单一的因素证实”你是你“，好比密码、PIN码
• Multi-factor - 有时候 Single-factor 没有办法保证”你是你“，就会须要一些多重验证的手段，好比动态口令、生物识别等
• 上面提到的是两种用的比较多的手段，还有一些其余的，好比安全问题，短信，email认证等等

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 2.0是什么

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

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

流程

1. 用户要访问SP上面的资源，可是SP要求提供用户身份信息
2. SP 会将用户跳转到 IDP，IDP 返回一个登录页面
3. 用户成功登录后IDP会提供一个 SAML Assertion，经过用户端传递给SP
4. 此时SP会验证这个 SAML Assertion，没有问题的话就会返回相应的资源
5. 若是后面用户又要访问该平台的另一个系统，因为该用户已经在IDP那边登陆过了，因此这次访问IDP就可以直接将用户的 SAML Assertion 传递给这个新的SP，即可以实现不登陆直接访问资源

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 redirect binding
• HTTP POST binding
• HTTP artifact binding
• SAML URI binding
• SAML SOAP binding(based on SOAP 1.1)
• reverse SOAP(PAOS) binding

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

• redirect binding是在SP redirect到IDP的时候会在URL中带上请求信息，好比id，谁发出来的等等
• POST binding是为了解决redirect方式在使用过程当中的一些问题而产生的，好比URL过长，response不安全等等
• artifact能够看作一个引用，这个引用会经过浏览器带到SP那边，SP拿到以后再经过里面的信息去IDP拿相应的 SAML Assertion

metadata

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

• NameFormat -- 约定用户ID的格式，好比 email address， transient等等
• Certificate -- 解析签名，加密assertion
• Entity identifier -- 该metadata的惟一标识符
• Binding -- 使用何种方式通讯

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

OIDC

OIDC是什么

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

它的结构如图所示：

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

• Discovery：发现服务，使客户端能够动态的获取 OIDC 服务相关的元数据描述信息（好比支持那些规范，接口地址是什么等等）
• Dynamic Registration ：可选。动态注册服务，使客户端能够动态的注册到OIDC的OP
• Session Management ：Session管理，用于规范OIDC服务如何管理Session信息
• OAuth 2.0 Form Post Response Mode：针对 OAuth2 的扩展，OAuth2 回传信息给客户端是经过URL的 querystring 和 fragment 这两种方式，这个扩展标准提供了一基于 form 表单的形式把数据 post 给客户端的机制

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

流程

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

• EU：End User，指使用终端(浏览器等)访问服务器资源的用户
• RP：Relying Party，用来代指 OAuth2 中的受信任的客户端，身份认证和受权信息的消费方，至关于 SAML 中的 SP
• OP：OpenID Provider，有能力提供EU认证的服务（好比OAuth2中的受权服务），用来为RP提供EU的身份认证信息，至关于 SAML 中的 IDP

• ID Token：JWT格式的数据，包含 EU 身份认证的信息。ID Token 由 JWS 进行签名和 JWE 加密，从而提供认证的完整性、不能否认性以及可选的保密性。里面可能会有不少字段，详细能够看这里，其中这几个字段是必定包含其中的

  • iss - Issuer Identifier：提供认证信息者的惟一标识，一般是一个 HTTPS 的 URL
  • sub - Subject Identifier：iss 提供的 EU 的标识，在 iss 范围内惟一，它会被 RP 用来标识惟一的用户，最长为255个ASCII个字符
  • aud - Audience(s)：标识ID Token的受众，必须包含 OAuth 2.0 的client_id
  • exp - Expiration time：过时时间，超过此时间的 ID Token 会做废再也不被验证经过
  • iat - Issued At Time：JWT的构建的时间
• UserInfo Endpoint：用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回受权用户的信息，此接口必须使用HTTPS
• APP Token：一般来讲 OP 提供的用户信息和 Access Token 中包含的信息不带有用户在 RP 中的权限，RP 一般会本身生成一个 token 给 EU 做为后续访问资源的用户证实

Authorization Code flow

1. EU 访问 RP 的资源可是没有进行身份认证

2. RP 将 EU redirect 到 OP 端，并带上一些参数，这里列举一些必选参数，还有许多可选参数能够看这里

   • client_id：惟一标识
   • scope：请求权限范围，OIDC的请求必须包含值为“openid”的scope的参数
   • response_type：要求 OP 的返回值，值为 code，token，id_token，none 中的一个或几个，在当前 flow 值为 code
   • redirect URL：认证完成后的跳转URL
   • state：当前登陆认证操做的一个随机 query，用于防止 CSRF 或 XSRF 攻击
3. 而后 OP 会验证 EU 的身份信息，一般会询问用户是否将本身的信息提供给 RP，确认后进行登陆操做
4. 登录成功后 OP 会将 EU redirect 到刚刚 RP 提供的 URL，同时会在 URL 中带上一个 Authorization Code 和刚刚的 state 参数
5. 以后 RP 拿到 code 和 state，先确认是否是相同的 state 保证此次通讯是有效的，以后再经过 POST 请求从 OP 获取 token，里面包含 ID Token，Access Token，Refresh Token，Token Type，Expired In 等信息
6. 以后 RP 会验证 ID Token 和验证 Access Token 确保它们没有问题
7. 而后 RP 经过 Access token 经过 OP 提供的 UserInfo Endpoint 获取用户信息，拿到用户信息后与本身的用户信息进行比对
8. 最后返回一个 APP Token 到 EU

Implicit Flow

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

Hybrid Flow

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

---

很是感谢你能看到这里，若是你以为有帮助到你，能够关注个人微信公众号