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