miller
发布于

OAuth 2.0 授权系统设计(以微信登录为例)

4A系统是统一安全管理平台解决方案,指 认证Authentication、账号Account、授权Authorization、审计Audit,中文名称为 统一安全管理平台解决方案。

怎么才算是安全?两部分:

  1. 怎么证明你是你? Authentication 即 身份验证、认证。

  2. 怎么相信你有权限做什么事情? Authorization 即 授权。


了解了Authentication 和 Authorization 后,再简单了解一下OAuth主要在做什么。

在这之前,先熟悉一下整个 OAuth 流程中的参与者(第一个重点知识)

  1. Resource Owner —— 资源拥有者,同时也是 Application 的用户

  2. Application —— 用户正在准备使用的web app (当然也可以是手机APP或其他应用,本文只关注web app)

  3. Authorization Server —— 授权服务器,所有的权限信息、安全信息都在这个服务器上管理

  4. Resource Server —— 资源服务器,存储资源、材料、内容的服务器

理解这4者的概念后,OAuth流程可以简单概况为:

资源拥有者(Resource Owner)在使用第三方应用(Application)时,通过授权服务器(Authorization Server)授予第三方应用(Application)在资源服务器(Resource Server)访问某些资源的权限。


在实际应用开发中,我们常常需要使用微信作为应用的登陆方式,不同于手 Q 登陆使用传统的 ptlogin,微信登陆采用了 OAuth 2.0 的验证方式。本文将以微信登录为案例,具体分析介绍所采用的 OAuth 2.0 验证方式。

  1. 场景介绍。

  2. 什么是 OAuth 2.0?

  3. 授权码模式介绍。

  4. 授权码模式具体到微信登录架构设计。

  5. OAuth 2.0 为什么不直接返回 access_token?

1. 场景介绍:

作为一个第三方应用,用户通过微信登录应用,应用方想获取用户的一些私密信息,如微信头像和微信昵称等。此时,有两种不同的开发方案:

方案 1:用户在第三方应用输入微信号和密码,应用方直接通过微信号和密码向微信服务器请求具体的信息。(显然是不现实的,微信也不会允许)

方案 2:通过 OAuth 2.0 验证方案,在第三方应用不知道用户密码甚至微信账号信息的情况下获取需要的信息。

2. 什么是 OAuth 2.0?

直白点说,OAuth 2.0 是个授权框架。它定义了第三方应用如何通过用户授权,来访问用户的受限资源。允许用户让第三方应用访问该用户在某服务的特定私有资源但是不提供账号密码信息给第三方应用。

OAuth 2.0 中 O 代表的是 Open,开放;Auth 代表的是 Authenticate 和 Authorize,即验证和授权。涉及到的关键参与方有以下四个:

  • resource owner:对应着 OAuth 1.0 中的 User 角色,授权过程中的主体。
  • client:对应着 OAuth 1.0 中 Consumer 的概念,通过申请获得 resource owner 的授权,从而实现访问受保护资源的第三方的软件或者服务,是授权过程中的客体。
  • resource server :存储着 resource owner 的受保护资源的服务器,可以通过验证 access token 来开放对 resource owner 的数据的访问。
  • authorization server:在 resource owner 授权完毕后,负责颁发 access token 的服务器。(实际项目中,resource server 和 authorization server 可能部署在一台服务器上,甚至根本就是一套服务进程。)

(A):客户端请求资源所有者的授权。
(B):资源所有者同意授权。
(C):客户端获得了资源所有者的授权之后,向授权服务器申请授权令牌。
(D):授权服务器验证客户端无误后发放授权令牌。
(E):客户端拿到授权令牌之后请求资源服务器发送用户信息。
(F):资源服务器验证令牌无误后将用户信息发放给客户端。

其中获得用户授权是重点,业界目前一共有四种授权方式:

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 用户端模式(client credentials)

3. 本文将主要介绍最常见使用的授权码模式,具体流程如下所示:

A、B 步骤用户使用第三方应用请求授权:第三方应用将资源所有者导向一个特定的地址,附带以下请求信息:

  • response_type:必选,请求类型。这里固定为 "code"。
  • client_id:必选,标识第三方应用的 id。很多地方也用 apppid 来代替。
  • redirect_uri:可选,授权完成后重定向的地址。当取得用户授权后,服务将重定向到这个地址,并在地址里附带上授权码。
  • scope:可选,第三方请求的资源范围。比如是想获取基本信息、敏感信息等。
  • state:推荐,用于状态保持,可以是任意字符串。授权服务会原封不动地返回。

C 步骤,第三方应用拿到授权请求的 response:资源所有者同意授权第三方应用访问受限资源后,请求返回,跳转到 redirect_uri 指定的地址。返回 body 有:

  • code:必选,授权码。后续步骤中,用来交换 access token。
  • state:必选(如果授权请求中,带上了 state),这里原封不动地回传。

D 步骤,第三方应用继续请求 access token:第三方应用向授权服务请求获取 access token。请求参数包括:

  • grant_type:必选,许可类型,这里固定为 “authorization_code”。
  • code:必选,授权码。在用户授权步骤中,授权服务返回的。
  • redirect_uri:必选,如果在授权请求步骤中,带上了 redirect_uri,那么这里也必须带上,且值相同。
  • client_id:必选,第三方应用 id。

E 步骤,授权服务返回给第三方应用 access token:请求合法且授权验证通过,那么授权服务将 access token 返回给第三方应用。返回 body 有:

  • access token:访问令牌,第三方应用访问用户资源的凭证。
  • access_token_expires_in:access token 的有效时长。
  • refresh token:更新 access token 的凭证。当 access token 过期,可以 refresh token 为凭证,获取新的 access token。
  • refresh_token_expires_in:refresh token 的有效时长。

4. 授权码模式具体到微信应用如下所示:

应用登录请求步骤和携带参数:

A,B --> 用户请求授权:请求带上 appid、redirect_uri、response_type、scope 和 state。

  • appid:应用 id,就是前面提到的 client_id。
  • redirect_uri:授权回调的地址,在微信管理后台填写。
  • response_type:响应类型,固定为 "code"。
  • scope:授权许可范围,固定为 "snsapi_login"。
  • state:可选,授权服务回传。

C --> 用户同意授权,重定向到 redirect_uri, 并返回临时票据 code。如下所示:

D--> 应用拿到 code,用 code 去获取 access token。携带参数如下:

  • appid:必选,应用 id。
  • secret:必选,应用秘钥,在微信后台生成。
  • code:必选,前面获取的授权码。
  • grant_type:必选,值固定为 "authorization_code"
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

E--> 微信后台验证,确认请求合法后,将 access token 返回给第三方应用。

access_token 是调用授权关系接口的调用凭证,由于 access_token 有效期(目前为 2 个小时)较短,当 access_token 超时后,可以使用 refresh_token 进行刷新,access_token 刷新结果有两种:

  • 若 access_token 已超时,那么进行 refresh_token 会获取一个新的 access_token,新的超时时间;
  • 若 access_token 未超时,那么进行 refresh_token 不会改变 access_token,但超时时间会刷新,相当于续期 access_token。

refresh_token 拥有较长的有效期(30 天),当 refresh_token 失效的后,需要引导用户重新登录授权,获取新的 refresh_token。

5. OAuth 2.0 为什么不直接返回 access_token? 要设定为返回 auth_code 之后再去请求 accessToken?

主要出于安全方考虑,防止中间人攻击。假设第三方应用、授权服务不直接通信,中间隔了一层代理。且第三方应用采用 HTTP 协议,这样恶意代理就能窃取 access token。因此,采用了通过 code 来交换 access token 的方式,来增加安全性。并且不能将 access token 直接给到用户侧,相对于用户侧网络环境的复杂性,第三方应用自身服务端的网络环境相对更安全。

特别注意:对于授权码和 access_token 的篡改,在 OAuth 1.0 中是反复的对 Code 和 Token 进行签名,来保证 Token 不会被篡改,但是 OAuth 2.0 中却没有,**因为 OAuth 2.0 是基于 Https 的,所以如果没有 Https 的支持 OAuth 2.0 可能还不如 OAuth 1.0。**在 OAuth 2.0 中,使用 HTTPS 可以说是必须的,而且 client 有义务验证证书的真假,防止中间人攻击,而 authorization server 和 resource server 都有义务申请可信任的第三方颁发的真实的 SSL 证书。

我是 pavel,一位憨憨傻傻的程序员,平时幽默又有才,专注于 Java,go,微服务,云开发。不定时发送些鹅厂程序员的工作 / 生活日常,请大家多多关注我的公众号——pavel 随笔!附带各种 Java 面试题!

https://zhuanlan.zhihu.com/p/417148995

浏览 (481)
点赞
收藏
评论