别再搞错!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协议。如果你有什么疑问可以留言讨论。
往期推荐