我之前的文章简单的介绍了OAuth 2.0 (在这里: https://www.cnblogs.com/cgzl/p/9221488.html), 还不是很全.
这篇文章我要介绍一下 OpenID Connect.
OAuth 2.0 不是身份认证协议OAuth 2.0 不是身份认证(Authentication)协议. 为什么有人会认为OAuth 2.0具有身份认证的功能? 这是因为OAuth2经常作为身份认证(Authentication)协议的一部分来使用. 例如在典型的OAuth2流程里, OAuth2经常会嵌入一些身份认证的事件.
那么身份认证(Authentication)是什么?
我们这里所说的身份认证就是指它可以告诉应用程序当前的用户是谁, 还有这些用户是否正在使用你的应用程序. 它是一种安全架构, 它可以告诉你用户是他们所声明的身份, 通常呢, 是通过提供一套安全凭据(例如用户名和密码)给应用程序来证明这一点.
而OAuth2则不管用户这些东西, OAuth2的客户端应用只考虑请求token, 得到token, 使用token访问API. 它不关心谁给客户端应用授权了, 也不关心是否有最终用户.\
身份认证(Authentication) vs 授权(Authorization)
引用《OAuth 2.0 in Action》里面的一个比喻来解释, 把身份认证看作是软糖, 而授权是巧克力. 这两种东西感觉略有相似, 但是本质上却截然不同: 巧克力是一种原料, 而软糖是一种糖果. 可以使用巧克力作为主要原料做出巧克力口味的糖果, 但是巧克力和软糖绝不是等价的.
尽管巧克力可以单独作为一种最终产品, 但在这个比喻里巧克力是一种非常有用原料, 它极具多样性, 可以用来做蛋糕, 冰激凌, 雪糕等等.
在这个比喻里 OAuth 2.0 就是巧克力, 它是众多web安全架构的一种多用途的基本成分.
而软糖, 是一种糖果. 有一种特别可口的软糖叫做巧克力软糖. 很显然, 巧克力在这种软糖里是主要成分, 但是它还需要其它原料成分和一些关键的流程把巧克力转化成巧克力软糖.
制做出的产品是软糖的形式, 它以巧克力为主要成分. 这叫使用巧克力来制作软糖, 所以说巧克力不等价于软糖.
在这个比喻里, 身份认证就更像软糖, 它需要一些关键的组件和流程, 而却要把这些组件和流程通过正确的组合起来并安全的使用, 针对这些组件和流程还是有很多的选项的.
可以说我们要制作巧克力软糖, 也就是需要一个基于OAuth2的身份认证协议. 而OpenID Connect就是这样的开放标准, 它可以工作于不同的身份供应商之间. OpenID Connect 基于 OAuth 2.0, 在此之上, 它添加了一些组件来提供身份认证的能力.
OpenID Connect的官方定义是: OpenID Connect是建立在OAuth 2.0协议上的一个简单的身份标识层, OpenID Connect 兼容 OAuth 2.0.
OAuth 2.0与身份认证协议的角色映射
想要基于OAuth2构建身份认证协议, 那么就需要把OAuth2里面的那些角色映射到身份认证的事务里面.
在OAuth2里面, 资源所有者(Resource Owner)和客户端应用(Client)经常在一起工作, 因为客户端应用代表了资源所有者. 而授权服务器(Authorization Server)和被保护的资源(Protected Resource)经常在一起, 因为授权服务器生成token, 而被保护的资源接收token. 所以说在最终用户/客户端应用 与 授权服务器/被保护资源 之前存在一个安全和信任的边界, 而OAuth2就是用来跨越这个边界的协议.
而在身份认证的事务里, 最终用户使用身份提供商(Identity Provider, IdP)登录到依赖方(Relying Party, RP, 可以理解为客户端).
总结一下前面这段话:
OAuth2里可以分为两部分: 1.资源所有者/客户端应用, 2.授权服务器/被保护资源.
身份认证协议里也是两大部分: 1.依赖方, 2.身份提供商.
所以考虑这样映射:
OAuth2里的授权服务器/被保护资源 ---- 身份认证协议里的身份提供商进行映射
OAuth2里面的资源所有者 ---- 身份认证协议里的最终用户
OAuth2的客户端应用 ---- 身份认证协议里的依赖方(RP).
OAuth2里, 资源所有者的权限会委派给客户端应用, 但这时该权限对应的被保护资源就是他们自己的身份信息. 也就是说他们授权给依赖方(RP), 让其可以知道现在是谁在使用应用, 而这就是身份认证事务本质.
依赖方现在就可以知道是谁在使用系统并且他们是如何登录进来的. 不过这里还需要用到另外一种token, 叫做ID token, 这种token携带着身份认证事件本身的信息.
那么为什么不使用OAuth2里的access token把这些事都一次性解决了呢?