IAM的主流身份验证方法之OIDC协议

一、OIDC协议介绍

1.OIDC简介

OpenID Connect（简称OIDC）是一种安全认证机制，第三方应用连接到身份认证服务器（Identify Service）获取用户信息，并把这些信息以安全可靠的方式返回给第三方应用。

OAuth2.0通过Access Token作为向第三方应用授权访问自身资源的凭证。OpenID Connect对OAuth2.0进行协议进行了扩展，通过扩展的ID Token字段，提供用户基础身份信息，ID Token使用JWT（JSON Web Token）格式进行封装，提供自包含性、防篡改机制，可以安全的传递给第三方应用程序并容易被验证。除了ID Token，还可以通过Access Token从认证服务的UserInfo Endpoint接口获取更详细的用户信息。

2.发展历史

• 2014年，OIDC规范发布。
• 2015年，OIDC认证计划启动。
• 2021年，OIDC联合规范第三实施者草案获得批准。
• 2022年，OIDC注销规范得以确定。

从这些时间点我们可以看出，OIDC的发展也是一个漫长且历经考验的过程，相对CAS、Oauth之类的协议，他具有长足的优势才能在的检验之后应用到大众的生活中，前面我们讲了一些用于单点登陆的身份协议，比如我们熟知的Oauth协议，Oauth从授权的角度来讲已经很完善了，为什么还会出现基于Oauth 2.0的OIDC协议呢，我们下面来进行介绍

3.为什么会出现OIDC？

大家已经学习过Oauth了，而且在生活中Oath的使用也相当广泛，而且相比于其他协议，Oauth安全性也有很大的提高，那么Oauth已经算是不错了，为什么还会有OIDC的出现呢，因为在Oauth协议的认证流程里，强调的是针对授权、授权范围以及给客户端哪些信息，并没有对用户有特殊的验证机制，换句话说，在Oauth流程中，它的重点是授权，那么OIDC呢，是认证。打个不太恰当的比方，Oauth只是门上插了一把钥匙，谁都可以打开这扇门，OIDC是指纹锁，只有特定的用户才可以打开。

4.OIDC和OAuth2.0的区别

Oauth流程注重的是授权，是验证统信实体是否有权限访问资源的过程，即“用户能做什么”，OIDC更注重认证的过程，确保通信实体是其所声称的实体，即“是哪一个用户”。

①OIDC流程中，授权服务器验证成功会响应会返回一个ID令牌，这在Oauth里是没有的。

②OIDC流程中客户端请求会在请求范围参数中包含字符串“openid”，当然，基本的OIDC架构是这样的，这一条并不绝对，因为随着OIDC的普及，我们也看到了一些重新开发过的OIDC实现，是没有这一部分的

③在Oauth的认证流程里，对于响应的令牌格式是没有规定，但是OIDC规定了令牌的格式为JWT。其实在实际应用的时候，很多Oauth其实也用的是JWT格式的令牌

5.OIDC协议前置知识

客户端：客户端指的是用户访问的web应用或者移动应用。也叫RP。

用户代理：用户代理指的是用户用于访问客户端的工具，通常为浏览器。

授权范围（scope）：OIDC规范明确定义了客户端向认证服务器发起授权请求时必须在请求的scope参数中声明授权范围。

ID令牌（id_token）：认证服务器验证用户身份后，除了向客户端返回响应令牌和刷新令牌，还会返回一个标识令牌所有者的ID令牌（id_token）。

响应类型（response_type）：响应类型请求参数response_type告知授权服务器所需的授权处理流程，包括从使用的端点返回的参数。

6.OIDC认证协议认证流程