OAUTH2.0协议-菜鸟级

OAUTH2.0入门必看

一、摘要
  OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。

二、简介
    An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

三、相关术语
  在进行了解OAUTH协议前,先要对有关的术语进行了解。
  1. URL
  URL,全称是Uniform Resoure Locator,翻译过来就是“统一资源定位符”。URL组成部分从左至右依次是:服务协议类型、服务器地址、端口号、路径和文件名。一个完整的URL包括–协议部分、网址、文件地址部分。协议部分以//为分隔符,在interner中,我们可以使用多种协议:
    a. HTTP:HyperText Transfer Protocol(超文本传输协议)
    b. FTP:File Transfer Protocol(文件传输协议)
    c. Gopher:The Internet Gopher Protocol(网际Gopher协议)
    d. File:本地文件传输协议
    e. HTTPS:安全套接字层超文本传输协议(http的安全版)
  2. Token
  令牌,代表执行某些操作的权利的对象。token一般由账号、密码、时间经过加密处理的标记(token)序列,用来访问或执行某系统的权限。类似于古代行军进程的令牌通行证。
  Token是在服务端产生的。如果前端使用用户名和密码向服务端发送请求认证,服务端认证成功,那么在服务端会返回Token给前端。前端可以在每次请求的时候带上Token证明自己的合法地位。如果Token在服务端持久化,那他就是一个永久的身份令牌。
  3.
  a. 访问令牌(Access token):表示访问控制操作主体的系统对象
  b. 邀请码:在邀请系统中使用
  c. Token, Petri 网(Petri net):理论中的Token
  d. 密保令牌(Security token) : 或者硬件令牌,例如U盾,或者叫做认证令牌或者加密令牌,一种计算机身份校验的物理设备
  e. 会话令牌(Session token): 交互会话中唯一身份标识符
  f. 令牌化技术 (Tokenization): 取代敏感信息条目的处理过程
  4. User Authentication
  用户认证;使用者认证;用户身份验证
  5.
  授权服务器负责用户登录、授权、token验证等。
  资源服务器负责提供受保护资源,只是需要到授权服务器进行token验证。

四、授权模式
  客户端获取授权的四种模式
  客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)。OAuth 2.0定义了四种授权方式。
    • 授权码模式(authorization code)
    • 简化模式(implicit)
    • 密码模式(resource owner password credentials)
    • 客户端模式(client credentials)
  (1)授权码模式(authorization code)
    功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动。
  (2)简化模式(implicit grant type)
    不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤,因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。
  (3)密码模式(Resource Owner Password Credentials Grant)
    用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下,比如客户端是操作系统的一部分,或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式。
  (4)客户端模式(Client Credentials Grant)
    指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题。
     注:web资源:其实就是接口。

五、授权步骤

简书采用微博授权登录流程

  • A. 使用者(第三方软件)向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求,请求需要带上的参数见上图。

  • B. OAUTH服务提供商同意使用者的请求,并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret,并返回给使用者。

  • C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向User Authorization URL发起请求,请求带上上步拿到的未授权的token与其密钥。

  • D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户,你想将哪些受保护的资源授权给该应用。(此步可能会返回授权的Request Token也可能不返回。如Yahoo OAUTH就不会返回任何信息给使用者。)

  • E. Request Token 授权后,使用者将向Access Token URL发起请求,将上步授权的Request Token换取成Access Token。请求的参数见上图,这个比第一步A多了一个参数就是Request Token。

  • F. OAUTH服务提供商同意使用者的请求,并向其颁发Access Token与对应的密钥,并返回给使用者。

  G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源。

原文地址:https://www.cnblogs.com/littlerachel/p/11978810.html

时间: 2024-11-16 05:36:28

OAUTH2.0协议-菜鸟级的相关文章

安全系列之二:OAuth2.0协议

本文提取出OAuth2.0规范RFC6749的主要内容,部分内容从文档复制出来,给大家讲讲第三方授权背后的故事. 先是举个知乎的QQ登录授权的例子,然后讲四种授权方式,两种令牌,接着是看看协议流程,分析知乎的QQ登录授权请求响应报文解释OAuth2.0协议,最后简单看看QQ提供第三方授权的API加深理解. 先打个预防针,在讲解四种授权,两种令牌时大家可能会有点不懂,但是跟随着协议流程走就懂了. 如果觉得排版不好,可以访问我的博客.TAT blog.bensonlin.me 如果觉得写得不错,欢迎

基于OAuth2.0协议 第三方登录与数据同步验证设计

前段时间,公司跟别的公司签订合作伙伴,搞了一个第三方登录与数据共享同步,是基于OAuth2.0协议,现在空闲了,做一下笔记. 到github下载一个OAuth2.0的PHP类库(当然,你也可以自己写一个^-^,但个人觉得没必要造轮子),有写好Mysql与Mongodb的Demo,参考一下,然后嵌套自己的业务代码,下面是客户端与服务端的交互流程: +-----------+ +-----------+| | 带client_id的URL请求获取code | || | ---------------

Oauth2.0协议曝漏洞 大量社交网站隐私或遭泄露

2014年是IT业界不平常的一年,XP停服.IE长老漏洞(秘狐)等等层出不穷,现在,社交网络也爆出惊天漏洞:Oauth2.0协议漏洞 继OpenSSL漏洞后,开源安全软件再曝安全漏洞.新加坡南洋理工大学研究人员Wang Jing发现,Oauth2.0授权接口的网站存“隐蔽重定向”漏洞,黑客可利用该漏洞给钓鱼网站“变装”,用知名大型网站链接引诱用户登录钓鱼网站,一旦用户访问钓鱼网站并成功登陆授权,黑客即可读取其在网站上存储的私密信息.据悉,腾讯QQ.新浪微博.Facebook.Google等国内外

接口测试工具-Jmeter使用笔记(八:模拟OAuth2.0协议简化模式的请求)

背景 博主的主要工作是测试API,目前已经用Jmeter+Jenkins实现了项目中的接口自动化测试流程.但是马上要接手的项目,API应用的是OAuth2.0协议授权,并且采用的是简化模式(implicit grant type).所以最近学习了一下该协议,并尝试用Jmeter模拟该授权方式的处理流程,以改进自动化测试脚本. 本文主要分为三个部分:1.简述OAuth2.0协议中的简化模式授权方式: 2.通过在浏览器上抓包,分析获取授权的过程中经历了什么: 3.尝试用Jmeter模拟整个授权过程,

轻松搭建CAS 5.x系列(6)-在CAS Server上增加OAuth2.0协议

概述说明 CAS Server默认搭建出来,客户端程序只能按照CAS自身的协议接入.CAS的强大在于,有官方的插件,可以支持其他的协议.本章节就让CAS Server怎么增加OAuth2.0的登录协议. 安装步骤 `1. 首先,您需要有个CAS Server端 如果您没有,可以按照我之前写的文章<轻松搭建CAS 5.x系列文章>系列的前3篇文章搭建好CAS Server. ·2. 在pom.xml增加依赖包 1 <!-- OAuth/OpenID Authentication Begin

OAuth2.0协议流程

1.客户端向从资源所有者请求授权.授权请求可以直接向资源所有者发起,或者更可取的是通过作为中介的授权服务器间接发起. 2.客户端收到授权许可,这是一个代表资源所有者的授权的凭据,使用本规范中定义的四种许可类型之一或 者使用扩展许可类型表示.授权许可类型取决于客户端请求授权所使用的方式以及授权服务器支持的类型. 3.客户端与授权服务器进行身份认证并出示授权许可请求访问令牌. 4.授权服务器验证客户端身份并验证授权许可,若有效则颁发访问令牌. 5.客户端从资源服务器请求受保护资源并出示访问令牌进行身

深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的"开放授权"思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如

Oauth2.0协议 http://www.php20.com/forum.php?mod=viewthread&amp;tid=28 (出处: 码农之家)

概要     OAuth2.0是OAuth协议的下一版本,但不向后兼容OAuth 1.0即完全废止了OAuth1.0. OAuth 2.0关注客户端开发者的简易性.要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限.同时为Web应用,桌面应用和手机,和起居室设备提供专门的认证流程.2012年10月,OAuth 2.0协议正式发布为RFC 6749 OAuth 1.0已经在IETF尘埃落定,编号是RFC5849这也标志着OAuth已经正

(转)帮你深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的"开放授权"思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如