RFC 6749

OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。

OAuth 引入了一个授权层,用来分离两种不同的角色:客户端和资源所有者。......资源所有者同意以后,资源服务器可以向客户端颁发令牌。客户端通过令牌,去请求数据。

这段话的意思就是,OAuth 的核心就是向第三方应用颁发令牌。然后,RFC 6749 接着写道:

(由于互联网有多种场景,)本标准定义了获得令牌的四种授权方式(authorization grant )。

也就是说,OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种,向第三方应用颁发令牌。下面就是这四种授权方式。

  • 授权码(authorization-code)
  • 隐藏式(implicit)
  • 密码式(password):
  • 客户端凭证(client credentials)

注意,不管哪一种授权方式,第三方应用申请令牌之前,都必须先到系统备案,说明自己的身份,然后会拿到两个身份识别码:客户端 ID(client ID)和客户端密钥(client secret)。这是为了防止令牌被滥用,没有备案过的第三方应用,是不会拿到令牌的。

第一种授权方式:授权码

授权码(authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌。

这种方式是最常用的流程,安全性也最高,它适用于那些有后端的 Web 应用。授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。

第一步,A 网站提供一个链接,用户点击后就会跳转到 B 网站,授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。


https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read

上面 URL 中,response_type参数表示要求返回授权码(code),client_id参数让 B 知道是谁在请求,redirect_uri参数是 B 接受或拒绝请求后的跳转网址,scope参数表示要求的授权范围(这里是只读)。

第二步,用户跳转后,B 网站会要求用户登录,然后询问是否同意给予 A 网站授权。用户表示同意,这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时,会传回一个授权码,就像下面这样。


https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中,code参数就是授权码。

第三步,A 网站拿到授权码以后,就可以在后端,向 B 网站请求令牌。


https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL

上面 URL 中,client_id参数和client_secret参数用来让 B 确认 A 的身份(client_secret参数是保密的,因此只能在后端发请求),grant_type参数的值是AUTHORIZATION_CODE,表示采用的授权方式是授权码,code参数是上一步拿到的授权码,redirect_uri参数是令牌颁发后的回调网址。

第四步,B 网站收到请求以后,就会颁发令牌。具体做法是向redirect_uri指定的网址,发送一段 JSON 数据。


{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}

上面 JSON 数据中,access_token字段就是令牌,A 网站在后端拿到了。

第二种方式:隐藏式

有些 Web 应用是纯前端应用,没有后端。这时就不能用上面的方式了,必须将令牌储存在前端。RFC 6749 就规定了第二种方式,允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)"隐藏式"(implicit)。

第一步,A 网站提供一个链接,要求用户跳转到 B 网站,授权用户数据给 A 网站使用。


https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read

上面 URL 中,response_type参数为token,表示要求直接返回令牌。

第二步,用户跳转到 B 网站,登录后同意给予 A 网站授权。这时,B 网站就会跳回redirect_uri参数指定的跳转网址,并且把令牌作为 URL 参数,传给 A 网站。


https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中,token参数就是令牌,A 网站因此直接在前端拿到令牌。

注意,令牌的位置是 URL 锚点(fragment),而不是查询字符串(querystring),这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议,因此存在"中间人攻击"的风险,而浏览器跳转时,锚点不会发到服务器,就减少了泄漏令牌的风险。

这种方式把令牌直接传给前端,是很不安全的。因此,只能用于一些安全要求不高的场景,并且令牌的有效期必须非常短,通常就是会话期间(session)有效,浏览器关掉,令牌就失效了。

第三种方式:密码式

如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)。

第一步,A 网站要求用户提供 B 网站的用户名和密码。拿到以后,A 就直接向 B 请求令牌。


https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID

上面 URL 中,grant_type参数是授权方式,这里的password表示"密码式",usernamepassword是 B 的用户名和密码。

第二步,B 网站验证身份通过后,直接给出令牌。注意,这时不需要跳转,而是把令牌放在 JSON 数据里面,作为 HTTP 回应,A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码,显然风险很大,因此只适用于其他授权方式都无法采用的情况,而且必须是用户高度信任的应用。

第四种方式:凭证式

最后一种方式是凭证式(client credentials),适用于没有前端的命令行应用,即在命令行下请求令牌。

第一步,A 应用在命令行向 B 发出请求。


https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

上面 URL 中,grant_type参数等于client_credentials表示采用凭证式,client_idclient_secret用来让 B 确认 A 的身份。

第二步,B 网站验证通过以后,直接返回令牌。

这种方式给出的令牌,是针对第三方应用的,而不是针对用户的,即有可能多个用户共享同一个令牌。

令牌的使用

A 网站拿到令牌以后,就可以向 B 网站的 API 请求数据了。

此时,每个发到 API 的请求,都必须带有令牌。具体做法是在请求的头信息,加上一个Authorization字段,令牌就放在这个字段里面。


curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

上面命令中,ACCESS_TOKEN就是拿到的令牌。

更新令牌

令牌的有效期到了,如果让用户重新走一遍上面的流程,再申请一个新的令牌,很可能体验不好,而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是,B 网站颁发令牌的时候,一次性颁发两个令牌,一个用于获取数据,另一个用于获取新的令牌(refresh token 字段)。令牌到期前,用户使用 refresh token 发一个请求,去更新令牌。


https://b.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN

上面 URL 中,grant_type参数为refresh_token表示要求更新令牌,client_id参数和client_secret参数用于确认身份,refresh_token参数就是用于更新令牌的令牌。

B 网站验证通过以后,就会颁发新的令牌。

1.客户端模式,用在纯后端应用的服务中。如果是纯接口交互,建议使用客户端模式。

2.密码模式,用在系统间高度信任的场景,因为有密码泄露的风险,不建议用在公网。
3.授权码模式,用在有前后端的服务中。

参考:http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

OAuth 2.0 的四种授权模式的更多相关文章

  1. 使用 spring-security-oauth2 体验 OAuth 2.0 的四种授权模式

    目录 背景 相关代码 授权码模式 第一步 访问GET /oauth/authorize 第二步 访问POST /oauth/authorize 第三步 访问POST /oauth/token 简化模式 ...

  2. OAuth2.0的四种授权模式

    1.什么是OAuth2 OAuth(开放授权)是一个开放标准,允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容,OA ...

  3. OAuth2.0的四种授权模式(转)

    1. OAuth2简易实战(一)-四种模式 1.1. 隐式授权模式(Implicit Grant) 第一步:用户访问页面时,重定向到认证服务器. 第二步:认证服务器给用户一个认证页面,等待用户授权. ...

  4. OAuth2.0 四种授权模式

    OAuth2.0简单笔记(四种授权模式) 金天:坚持写东西,不是一件容易的事,换句话说其实坚持本身都不是一件容易的事.如果学习有捷径,那就是不断实践,不断积累.写笔记,其实是给自己看的,是体现积累的一 ...

  5. OAuth 2.0 的四种方式

    上一篇文章介绍了 OAuth 2.0 是一种授权机制,主要用来颁发令牌(token).本文接着介绍颁发令牌的实务操作. 下面我假定,你已经理解了 OAuth 2.0 的含义和设计思想,否则请先阅读这个 ...

  6. 一口气说出 OAuth2.0 的四种鉴权方式,面试官会高看一眼

    本文收录在个人博客:www.chengxy-nds.top,技术资源共享,一起进步 上周我的自研开源项目开始破土动工了,<开源项目迈出第一步,10 选 1?页面模板成了第一个绊脚石 > , ...

  7. SQL中常用模糊查询的四种匹配模式&&正则表达式

    执行数据库查询时,有完整查询和模糊查询之分.一般模糊语句如下:SELECT 字段 FROM 表 WHERE 某字段 Like 条件 其中关于条件,SQL提供了四种匹配模式:1.%:表示任意0个或多个字 ...

  8. ThinkPHP的四种URL模式 URL_MODEL

    ThinkPHP支持四种URL模式,可以通过设置URL_MODEL参数来定义,包括普通模式.PATHINFO.REWRITE和兼容模式. 普通模式 设置URL_MODEL 为0 采用传统的URL参数模 ...

  9. 【转】JavaScript中的this关键字使用的四种调用模式

    http://blog.csdn.net/itpinpai/article/details/51004266 this关键字本意:这个.这里的意思.在JavaScript中是指每一个方法或函数都会有一 ...

随机推荐

  1. SSH登录服务器慢

      最近频繁遇到ssh登录到服务器验证慢的这个问题,今天抽时间总结下原因以及解决办法. UseDNS   登录到服务器端查看sshd_config配置文件,当UseDNS项配置为yes时(默认情况下可 ...

  2. testcontainers 方便的db测试框架

    testcontainers是一个强大,简单,基于容器的db测试解决方案 目前已经支持了主流的开发语言 参考资料 https://github.com/testcontainers/testconta ...

  3. 知识点总结 JS(ES6)

    一.新增数据类型Symbol 概念: Symbol代表独一无二的 Symbol类型的值通过Symbol函数来生成,同时Symbol函数返回的值的唯一的 Symbol函数可以接收字符串作为参数,但是即使 ...

  4. DP问题(2) : hdu 1421

    题目转自hdu 1421,题目传送门 题目大意: 给你n个物品,你要搬走2*k个(也就是搬k次) 每次搬需要花费v,v=(ai-aj)2 (i表示左手拿的物品重量,j表示右手拿的物品的重量) 要求所有 ...

  5. 爬虫解析库:XPath

    XPath     XPath,全称 XML Path Language,即 XML 路径语言,它是一门在 XML 文档中查找信息的语言.最初是用来搜寻 XML 文档的,但同样适用于 HTML 文档的 ...

  6. App.vue 不触发 beforeRouteEnter

    因为要在 router 对应一个路由的组件才可以触发 如果没有将 App.vue 作为某个路由组件(一般不会吧) 就不会触发该导航守卫 应该是想在每次进入应用时加载一些数据 所以放在 App.vue ...

  7. 2条最佳实践App疯狂增长逻辑

    2条最佳实践App疯狂增长逻辑 1.不断打造和强化产品的不可或缺属性 产品的核心价值是什么?对你的客户来言,为什么是你? 2.等待“阿哈时刻” 进入快速推广 用户使用产品眼前一亮的时刻,是用户真正发现 ...

  8. Jquery表单插件使用

    一般表单提交都是同步,可以使用$.post进行异步提交,但这样意味着当表单属性很多的时候,要写的js也很多($("#xxx").val()获取属性的值后,在放入$.post第二个参 ...

  9. layui.dropdown.js

    前 在 layui 框架下做了一个小组件,是下拉框功能,当然也可以很好的变成其他组件,前提你会修改. 还需要更多的完善.后期(我也不清楚会是啥时候会优化)

  10. tomcat闪退的解决思路

    用Tomcat总会遇到启动Tomcat闪退的问题. 什么叫闪退啊,就是闪一下,就退出了控制台. 都闪退了,为啥闪退也不知道呀,又没有错误信息,所以就要先阻止闪退,先看到错误信息,知道启动不起来的原因. ...