OAuth 2.0

一、OAuth 2.0

1.1 概述

  • 认证授权协议,明确了授权流程
    • 认证
      • Authentication is knowing the identity of the user
    • 授权
      • 指的是resource owner同意client访问其拥有的受保护的资源
      • 与请求处理过程中的Authorization有所区别
        • Authorization is deciding whether a user is allowed to perform an action
  • OAuth包含四个角色
    • resource owner
      • An entity capable of granting access to a protected resource
    • resource server
      • The server hosting the protected resources, capable of accepting
        and responding to protected resource requests using access tokens
    • client
      • An application making protected resource requests on behalf of the
        resource owner and with its authorization
    • authorization server
      • The server issuing access tokens to the client after successfully
        authenticating the resource owner and obtaining authorization
      • 寄宿受保护资源和签发token的服务器可以是同一个
  • 四种角色之间的交互可以用下图表示
    在这里插入图片描述
    • 其中,A表示询问resource owner对资源访问的同意,A、B这一过程通常需要以authorization server为中间媒介
    • OAuth定义了Authorization Grant的四种类型
      • authorization code
      • implicit
      • resource owner password credentials
      • client credentials
  • refresh token
    在这里插入图片描述
  • Protocol Endpoints
    • authorization server endpoints
      • Authorization endpoint
        • used by the client to obtain authorization from the resource owner via user-agent redirection
      • Token endpoint
        • used by the client to exchange an authorization grant for an access token, typically with client authentication
    • client endpoint
      • Redirection endpoint
        • used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent
        • 从authorization server切换回client
    • 不是每一个Authorization Grant Type都利用了所有的Protocol Endpoints

1.2 Authorization Code

  • 认证授权过程
    在这里插入图片描述
  • Authorization
    • Request
      • response_type,client_id,redirect_uri,scope,state
    • Response
      • code,state
  • Access Token
    • Request
      • grant_type
      • code
      • redirect_uri
      • client_id
  • 适用场景
    • client为server-side,代码运行在服务器

1.3 Implicit Flow与PKCE

1.3.1 Implicit Flow

  • 认证授权过程
    在这里插入图片描述
  • Authorization
    • Request
      • response_type,client_id,redirect_uri,scope,state
    • Response
      • access_token,token_type,expires_in,scope,state
  • 适用场景
    • client为client-side,代码运行在客户端,一般为javascript脚本

1.3.2 PKCE

  • Implicit的缺陷
    • token签发后会作为重定向的queryString返回,重定向跳转时会在历史记录里保存,浏览器中的插件等可以读取
    • 不包括客户端身份认证
      • 虽然某些情况下可以通过重定向URI确认客户端身份,但安全性降低
  • PKCE是对Authorization Code的拓展,在client-side实现
  • PKCE认证授权过程
    在这里插入图片描述
  • PKCE的特点
    • 与Implicit类似,代码运行在client-side,一般为浏览器
    • 与Implicit的token会保存在历史记录中相比,PKCE只有Authorization Code会保存在历史记录里
      • Authorization Code即使被劫持,随机生成的code_verifier可以帮助校验Authorization Code是否有效
      • code_verifier保存在client内存中

1.4 Password Grant

  • 认证授权过程
    在这里插入图片描述
  • Access Token
    • Request
      • grant_type,username,password,scope
  • 适用场景
    • client与resource server是属于同一系统内部

1.5 Client Credentials

  • 认证授权过程
    在这里插入图片描述
  • 适用场景
    • client为resource owner
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值