OAuth2.0学习笔记

应用场景

在传统“客户端-服务器”的认证模型中,客户端向服务器请求访问受限的资源时,需要使用资源所有者(即用户)的许可凭证(比如账号密码等)来得到服务器的认证。为了让第三方应用访问受限资源,资源所有者必须提供他的凭证给第三方。这就可能会存在一些问题,比如第三方应用需要存储用户账号密码方便以后使用,但是却以明文形式存储;或者用户授权给第三方应用之后却无法撤回自己的授权,只能更改密码……

原理

OAuth通过引入一个“授权层”(authorization layer),并且将客户端角色和资源所有者角色分离开来解决上述问题。在OAuth中,客户端不能直接登录服务提供商,只能登录授权层,并且客户端需要得到一个access token的令牌才可以访问资源。access token是经过资源所有者同意后,由授权服务器颁发给第三方客户端。客户端再使用该访问令牌访问资源服务器上的受限资源。

例如,一个用户(resource owner)想要授权打印服务(client)访问他云盘(resource server)中的照片,不需要提供账号密码就可以进行打印。他直接与云盘的授权服务器(authorization server)进行验证,然后授权服务器发送访问令牌给打印服务就可以了。

工作流程

OAuth定义了四种角色:

  • resource owner:即用户
  • resource server:托管资源的服务器
  • client:即第三方应用
  • authorization server:颁发访问令牌的服务器,可能与资源服务器是同一个
  • user agent:一般指浏览器

授权方式如下:

image

A. 用户打开客户端后,客户端请求用户授权
B. 客户端收到一个授权许可
C. 客户端向授权服务器申请访问令牌
D. 授权服务器对客户端和用户授权许可检验后,如果有效则发放访问令牌
E. 客户端使用访问令牌向资源服务器请求资源
F. 资源服务器验证访问令牌,如果有效则提供资源

授权模式

OAuth提供了四种授权模式。

授权码模式(Authorization Code)

授权码模式是使用一个“授权服务器”作为客户端和用户之间的中介。客户端通过重定向引导用户访问授权服务器,然后携带授权码再返回到客户端。

image

隐式模式(Implicit)

隐式模式简化了“授权码”步骤,针对一些使用诸如JavaScript等脚本语言的客户端。隐式模式中,客户端不用获得授权码,而是经过用户授权后直接得到令牌。

image

密码模式(Resource Owner Password Credentials)

用户向客户端提供自己的凭证(如用户名密码),客户端通过这些信息向资源服务器索要令牌。通常用在用户对客户端高度信任的前提下,并且其他授权模式无法使用时。
尽管客户端获得用户凭证,但是用户凭证用于单次请求和交换令牌,客户端不存储用户凭证,而是通过用户凭证换取一个长期访问令牌或更新令牌。

image

客户端凭证模式(Client Credentials)

客户端以自己名义,向服务提供商进行认证。用户直接向客户端注册,客户端以自己的名义要求服务提供商提供服务,其中不存在授权问题。

image

令牌

Access Token

访问令牌是用于访问受保护资源的凭证,是一串发给已授权客户端的字符串。令牌有访问范围和时间限制。

Refresh Token

更新令牌是用来获取访问令牌的凭证,由授权服务器颁发给客户端,若当前访问令牌过期,可通过更新令牌申请新的访问令牌。更新令牌从授权服务器发出一般会同访问令牌一起。

安全问题

(未完待续)

参考文章

RFC 6749
理解OAuth 2.0——阮一峰

原文地址:https://www.cnblogs.com/KRDecad3/p/15272579.html