OAuth 2.0只是授权协议，OIDC才是认证授权协议
OAuth 2.0只是授权协议，OIDC才是认证授权协议
上一文我们对Keycloak保护Spring Boot应用进行了实操。让大家见识到了Keycloak的强大。为了掌握Keycloak就必须对OpenID Connect（OIDC）协议进行了解。OIDC是OAuth 2.0的一个扩展协议。它为什么要扩展OAuth 2.0？在搞清楚这个问题之前我们需要再回顾一下OAuth 2.0协议。
OAuth 2.0
以往胖哥也说了不少OAuth 2.0协议相关的东西，但是依然让大家云里雾里。所以今天我们换一个角度来说一说OAuth 2.0。如今利用这个协议搞开放API的越来越多了。
为什么要开放授权
假如我开发了一个互联网照片存储服务，这里叫它XX相册存储服务，经过精心的运营用户量达到了一定的规模，这个时候往往会进入一个瓶颈期，我希望进一步提升这个品牌的知名度以改变这种现状。而另一个第三方照片打印平台也看中了我的独特优势，希望我能开放一些功能出来给他们调用。
强强联合，做大做强！我觉得这是一个好主意，它用了我的开放服务后也可以帮我引流用户、扩大我的影响力。从用户角度来看，可以同时享受照片云储存、云打印服务是非常具有吸引力的。所以开放一些功能给第三方是非常划算的。
客户端授权接入
虽然开放授权的好处很多，但是也不能没有规则。用户的隐私保护、数据安全都是非常重要的。经过仔细斟酌，我确定了下面几条开放的原则：
- 第三方需要在我的平台开个户，这样方便我对第三方平台进行管理和审计。哪个第三方不合规我就限流甚至封停其资格。
- 明确开放的接口类目并对其进行权限分类。用来满足不同层次的第三方。有的第三方只能获取用户信息；有的第三方可以调用云打印。方便后续
收费恰饭。 - 调用这些服务必须征求照片的实际拥有者（资源拥有者）同意，这是一个法律问题。获取用户的信息和资源必须征得用户同意才行。
于是第三方打印平台按照我制定的规则提请了一个接入申请，审核通过后我给他发了一套客户端凭证，包含了clientId和对应的secret，并明确告知第三方可以申请哪些功能，然后第三方就可以根据API文档进行开发了。
授权流程
用户登录了照片打印平台，发现居然还提供从XX相册存储服务拉取照片打印的功能。便兴冲冲地尝试了一下 。大致的过程是这样的：
用户告诉打印平台: 听说你能从XX相册存储服务把我照片给拉过来打印，给我操作一下。打印平台回复用户：没问题，不过我得先给XX相册存储服务说一下。我得带上我自己的标识clientId，还有你请求的事项权限scopes。以及遵循的流程类型authorizationGrantType。为了安全起见我们最好弄个state随机码防止中间人攻击。XX相册存储服务会通过我提供的专线redirectUri进行给您确认，您到时候确认一下。XX相册存储服务向用户确认：您是不是要授权给XX打印平台拉取您的照片？用户确认的话需要向XX相册存储服务提供自己的用户凭证并确认；否则拒绝，流程到此结束。XX相册存储服务收到用户的确认信息后回复打印平台: 用户确认过了，给您一个临时凭证code(authorizationGrantType=code) ，你来换Token然后就可以凭此拉取该用户的照片了。打印平台换取了Token成功地拉取了该用户的照片并打印。- 用户不用来回奔波就享受了跨平台云打印服务，用户体验度得到了提升。
OIDC的产生背景
OAuth 2.0协议只解决了授权的问题，客户端只要得到了资源所有者的授权就能访问资源。OAuth 2.0本身并没有提供用户认证的规范。
OAuth 2.0本身无法证明资源所有者就是正确的资源所有者。OAuth 2.0中涉及的用户认证都建立在其它认证的可靠性之上，OAuth 2.0只消费认证的结果并不参与认证的流程。
基于这个原因OpenID Connect诞生了。它和OAuth 2.0的关系是这样的：
interface OIDC extends OAuth2{
boolean authentication ()
}
也就是说OIDC 在OAuth 2.0 的基础之上增加一个对资源所有者的认证流程，实现了真正意义上的认证授权。基于篇幅的原因，我会在后续系列文章中和大家共同学习OIDC协议。如果你有什么疑问可以留言讨论。