查看原文
其他

OAuth2.0协议扩展——OIDC认证协议的基本概念

请关注星标 码农小胖哥 2021-11-13

前言

上一文里我们通过一个例子回顾了OAuth 2.0的流程,同时指出了OAuth 2.0的局限性:客户端无法认定资源拥有者就是正确的拥护者,虽然市面上的OAuth 2.0能够保证授权的安全性,但是OAuth 2.0本身并没有对用户认证提供明确的规范。这就是OIDC产生的契机。

OIDC

OIDCOAuth 2.0的一个变种。

OIDC(OpenID Connect)建立在Auth 2.0的流程之上,提出了终端用户认证标识ID Token概念。符合OIDC流程的一定符合OAuth2.0OAuth 2.0 是关于如何发布访问令牌(AccessToken)的规范;而OIDC是关于如何发布ID 令牌的规范。虽然这两种令牌都是以JWT的形式体现。

RFC 6749中定义的一个OAuth2.0授权端点(authorization endpoint) 用以请求授权,该端点需要一个response_type的参数用来通知授权服务器所需的授权类型,通常包括了codetoken两种。OIDC扩展了这一属性,增加了id_tokennone。那么response_type的值现在可能有下列组合的情况:

  1. code
  2. token
  3. id_token
  4. code token
  5. id_token token
  6. code id_token
  7. code id_token token
  8. none

另外如果该请求是一个OIDC授权认证请求还必须包含一个值为openidscope参数,这是区分普通OAuth 2.0OIDC的关键。

OIDC的关键术语

OIDC规定了一些术语用来提高我们学习的门槛:

  1. EU:End User 终端用户
  2. RP:Relying Party  即客户端(client),授权和认证的最终消费方,我搞不懂为啥要玩多余的概念
  3. OP:OpenID Provider,对EU进行认证的服务提供者
  4. ID Token:JWT格式,EU的认证通过后生成凭证,供RP消费
  5. UserInfo Endpoint:通过凭据查询用户基本信息的接口,建议上HTTPS。

OIDC的流程

OIDC复用了OAuth2.0的授权流程,在授权的过程中增加了一些“小动作”来进行用户认证。结合其术语,大致的流程是这样的:

  1. RP发送一个认证请求给OP;
  2. OP先对EU进行身份认证,确认无误后提供授权;
  3. OP把ID Token和Access Token(需要的话)返回给RP;
  4. RP使用Access Token发送一个请求UserInfo EndPoint;(可选)
  5. UserInfo EndPoint返回EU的Claims。(基于第4个步骤可选)
OIDC协议流程图

另外,OIDC归纳了三种复用OAuth 2.0的流程:

  1. Authorization Code Flow:使用OAuth2的Authorization Code模式来换取Id Token和Access Token。
  2. Implicit Flow:使用OAuth2的Implicit模式获取Id Token和Access Token。
  3. Hybrid Flow:以上两种的混合实现。

总结

协议这个东西学起来确实比较枯燥难懂,需要结合一些场景才能说清楚,说实话有些东西我也云里雾里,不过这个是无法跳过去的东西。先不要想太多为什么,后续会结合一些场景来搞明白上面的术语和流程。


: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存