OAuth2.0
Scope
客户端在请求授权时, 需要通过 scope 来指定需要访问的用户信息. 授权方在授权认证时会将对应的权限信息展示给用户, 以便用户决定是否将相应信息授权给客户端.
客户端可以请求多个scope, 每个表示scope的字符串以空格进行分割.
scope的定义由授权方决定.
OAuth Grant Types
Authorization Code Grant
客户端通过 client_id 构造授权链接, 用户在访问授权链接进行授权后, 通过授权链接传递的 redirect_uri, 携带一个 code 重定向回客户端. 客户端可通过 code和client_secret 向授权方获取 AccessToken, 再通过AccessToken来获取用户信息.
除了需要在授权链接中指定 scope来限制应用程序访问用户信息的权限外, 多数授权方允许在链接中传递state等参数, 在重定向跳转回客户端时, 透传回给客户端, 以便于客户端进行一些功能上的定制.
多数情况下, 授权方会对 redirect_uri指向的地址做校验或约束, 如限制域名和路径, 避免重定向 URI 被恶意篡改导致的授权码失窃.
这种授权方式常见于各种 Web 网站的第三方登录.
Proof Key for Code Exchange(PKCE)
PKCE 流程是对Authorization Code Grant的一种补充, 旨在避免 CSRF 和 授权码注入攻击.
Client Creates a Code Verifier
第一步, 客户端需要构造一个从[A-Z], [a-z], [0-9], "-", ".", "_", "~" 中随机至少 43 位的字符串. 该字符串必须无法猜测以保证安全.
Client Creates the Code Challenge
第二步, 客户端需要基于 Code Verifier的 Code Challenge.
虽然规范允许 Code Verifier直接按明文作为Code Challenge, 但一般不推荐.
推荐先对Code Verifier进行 SHA256 算法进行摘要, 再进行 URL-Safe 的 Base64编码值作为Code Challenge.
Client Sends the Code Challenge with the Authorization Request
第三步, 客户端在构造授权请求时, 携带 Code Challenge 和一个可选的 code_challenge_method.
Server Returns the Code
第四步, 授权方在返回授权码前, 必须将授权码和Code Challenge以及code_challenge_method进行关联.
如果授权方要求使用 PKCE而客户端未提供参数时, 授权方在响应时必须在 error 中明确是invalid_request, 并且在error_description或error_uri中解释是code challenge required.导致的错误.
Client Sends the Authorization Code and the Code Verifier to the
第五步, 客户端在拿到授权码后, 向授权方换取 AccessToken时, 除了需要传递授权码, 还需要传递Code Verifier参数.
Server Verifies code_verifier before Returning the Tokens
第六步, 授权方根据 code 以及关联的Code Challenge和code_challenge_method, 比对接受到的code_verifier进行计算, 来验证请求.