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

在了解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 20 和 OIDC。

SAML 20是什么

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

SAML 20是该协议的最新版本，于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 20 有许多不同的 binding，它们其实就是 SAML Assertion 的交互方式：

其中现在用的比较多的是前三种，它们都是基于>两个站点如果在同域下，那么它们之间是可以共享cookie的。简单的说就是这种同域下不同站点的sso实现可以通过cookie来实现，当用户访问这个域下面的任意站点时，浏览器都会将这个cookie发送给站点对应的系统。
举个简单的例子：
站点1: >单点登录Single Sign On简称为SSO，是目前比较流行的企业业务整合的解决方案之一。F5 BIG-IP Edge Gateway解决方案借助SSO改进用户体验。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

企业应用集成（EAI）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面
上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还
用一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。
单点登录的技术实现机制：当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；
根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
可以看出，要实现SSO，需要以下主要的功能：
所有应用系统共享一个身份认证系统；
所有应用系统能够识别和提取ticket信息；
应用系统能够识别已经登录过的用户，能自动判断当前用户是否登录过，从而完成单点登录的功能。
其中统一的身份认证系统最重要，认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。

F5 BIG-IP Edge Gateway解决方案借助SSO改进用户体验，简化移动/远程员工的身份验证流程不仅能够提升用户体验，还能够最大限度降低安全风险，并减少密码锁闭呼叫帮助中心的次数。F5 BIG-IP Edge Gateway能够缓存登录证书，并支持在登录过程中身份验证。如果发生连接掉线，用户将被自动重新执行身份验证。

企业发展初期，企业使用的系统很少，通常一个或者两个，每个系统都有自己的登录模块，运营人员每天用自己的账号登录，很方便。
但随着企业的发展，用到的系统随之增多，运营人员在 *** 作不同的系统时，需要多次登录，而且每个系统的账号都不一样，这对于运营人员
来说，很不方便。于是，就想到是不是可以在一个系统登录，其他系统就不用登录了呢？这就是单点登录要解决的问题。
单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。
image
如图所示，图中有4个系统，分别是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他的业务模块，当Application1、Application2、Application3需要登录时，将跳到SSO系统，SSO系统完成登录，其他的应用系统也就随之登录了。这完全符合我们对单点登录（SSO）的定义。
技术实现
在说单点登录（SSO）的技术实现之前，我们先说一说普通的登录认证机制。
image
如上图所示，我们在浏览器（Browser）中访问一个应用，这个应用需要登录，我们填写完用户名和密码后，完成登录认证。这时，我们在这个用户的session中标记登录状态为yes（已登录），同时在浏览器（Browser）中写入Cookie，这个Cookie是这个用户的唯一标识。下次我们再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户是否登录。如果不做特殊配置，这个Cookie的名字叫做jsessionid，值在服务端（server）是唯一的。
同域下的单点登录
一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名叫做：acom，同时有两个业务系统分别为：app1acom和app2acom。我们要做单点登录（SSO），需要一个登录系统，叫做：ssoacom。
我们只要在ssoacom登录，app1acom和app2acom就也登录了。通过上面的登陆认证机制，我们可以知道，在ssoacom中登录了，其实是在ssoacom的服务端的session中记录了登录状态，同时在浏览器端（Browser）的ssoacom下写入了Cookie。那么我们怎么才能让app1acom和app2acom登录呢？这里有两个问题：
Cookie是不能跨域的，我们Cookie的domain属性是ssoacom，在给app1acom和app2acom发送请求是带不上的。
sso、app1和app2是不同的应用，它们的session存在自己的应用内，是不共享的。
image
那么我们如何解决这两个问题呢？针对第一个问题，sso登录以后，可以将Cookie的域设置为顶域，即acom，这样所有子域的系统都可以访问到顶域的Cookie。我们在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。比如：我们不能在自己的系统中给baiducom的域设置Cookie。
Cookie的问题解决了，我们再来看看session的问题。我们在sso系统登录了，这时再访问app1，Cookie也带到了app1的服务端（Server），app1的服务端怎么找到这个Cookie对应的Session呢？这里就要把3个系统的Session共享，如图所示。共享Session的解决方案有很多，例如：Spring-Session。这样第2个问题也解决了。
同域下的单点登录就实现了，但这还不是真正的单点登录。
不同域下的单点登录
同域下的单点登录是巧用了Cookie顶域的特性。如果是不同域呢？不同域之间Cookie是不共享的，怎么办？
这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。
cas_flow_diagram
上图是CAS官网上的标准流程，具体流程如下：
用户访问app系统，app系统是需要登录的，但用户现在没有登录。
跳转到CAS server，即SSO登录系统，以后图中的CAS Server我们统一叫做SSO系统。 SSO系统也没有登录，d出用户登录页。
用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同时将ST作为参数传递给app系统。
app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
验证通过后，app系统将登录状态写入session并设置app域下的Cookie。
至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。
用户访问app2系统，app2系统没有登录，跳转到SSO。
由于SSO已经登录了，不需要重新登录认证。
SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
app2拿到ST，后台访问SSO，验证ST是否有效。
验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。
这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。
有的同学问我，SSO系统登录后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，觉得这个步骤有点多余。他想SSO登录认证通过后，通过回调地址将用户信息返回给原业务系统，原业务系统直接设置登录状态，这样流程简单，也完成了登录，不是很好吗？
其实这样问题时很严重的，如果我在SSO没有登录，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是不是业务系统也认为登录了呢？这是很可怕的。
总结
单点登录（SSO）的所有流程都介绍完了，原理大家都清楚了。总结一下单点登录要做的事情：
单点登录（SSO系统）是保障各业务系统的用户资源的安全 。
各个业务系统获得的信息是，这个用户能不能访问我的资源。
单点登录，资源都在各个业务系统这边，不在SSO那一方。 用户在给SSO服务器提供了用户名密码后，作为业务系统并不知道这件事。 SSO随便给业务系统一个ST，那么业务系统是不能确定这个ST是用户伪造的，还是真的有效，所以要拿着这个ST去SSO服务器再问一下，这个用户给我的ST是否有效，是有效的我才能让这个用户访问。

SSO是单点登录的简称，常用的SSO的协议有两种，分别是SAML和OAuth2。本文将会介绍两种协议的不同之处，从而让读者对这两种协议有更加深入的理解。

SAML的全称是Security Assertion Markup Language， 是由OASIS制定的一套基于XML格式的开放标准，用在身份提供者（IdP）和服务提供者 (SP)之间交换身份验证和授权数据。

SAML的一个非常重要的应用就是基于Web的单点登录（SSO）。

在SAML协议中定义了三个角色，分别是principal：代表主体通常表示人类用户。identity provider (IdP)身份提供者和service provider (SP)服务提供者。

IdP的作用就是进行身份认证，并且将用户的认证信息和授权信息传递给服务提供者。

SP的作用就是进行用户认证信息的验证，并且授权用户访问指定的资源信息。

接下来，我们通过一个用SAML进行SSO认证的流程图，来分析一下SAML是怎么工作的。

上图中User Agent就是web浏览器，我们看一下如果用户想请求Service Provider的资源的时候，SAML协议是怎么处理的。

SP将会对该资源进行相应的安全检查，如果发现已经有一个有效的安全上下文的话，SP将会跳过2-7步，直接进入第8步。

RelayState是SP维护的一个状态信息，主要用来防止CSRF攻击。

其中这个SAMLRequest是用Base64编码的<samlp:AuthnRequest>，下面是一个samlp:AuthnRequest的例子：

为了安全起见，SAMLRequest还可以使用SP提供的签名key来进行签名。

IdP收到这个AuthnRequest请求之后，将会进行安全验证，如果是合法的AuthnRequest，那么将会展示登录界面。

这个form中包含了SAMLResponse信息，SAMLResponse中包含了用户相关的信息。

同样的SAMLResponse也是使用Base64进行编码过的<samlp:Response>。

我们可以看到samlp:Response中包含有saml:Assertion信息。

我们可以看到上面的所有的信息交换都是由前端浏览器来完成的，在SP和IdP之间不存在直接的通信。

这种全部由前端来完成信息交换的方式好处就是协议流非常简单，所有的消息都是简单的GET或者POST请求。

如果为了提高安全性，也可以使用引用消息。也就是说IdP返回的不是直接的SAML assertion，而是一个SAML assertion的引用。SP收到这个引用之后，可以从后台再去查询真实的SAML assertion，从而提高了安全性。

SAML协议是2005年制定的，在制定协议的时候基本上是针对于web应用程序来说的，但是那时候的web应用程序还是比较简单的，更别提对App的支持。

SAML需要通过>

sso单点登录原理是当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改。

单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。

使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。

扩展资料

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

另外：

1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和校验，无论用户信息存储在什么地方，都能实现单点登录。

2、统一的认证系统并不是说只有单个的认证服务器

当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。

如果我们的网站需要和另一个域名做统一认证，也就是在我们网站登录，但真正的功能却在另一个网站来提供。许多都以 passport 的方式。 整个认证可以分三步完成 第一步：本地验证
这个很简单，输入本地的用户名和密码，然后服务器认证通过，并返回正确的Cookie;
第二步：做远程认证，并返回远程连接
通过本地Cookie,确认用户合法性，然后服务器端调用远程的登录程序，返回一个远程认证号的URL,这个URL里面包含了一个唯一的认证码，使用Location的方式
第三步：远程登录
客户端使用前一步的URL,访问远程的服务器，服务器确认认证码的正确性，再返回正确的远程Cookie
至此，本地认证，通过一个URL,实现了远程认证。

---