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资源:其实就是接口。

五、授权步骤

 

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

扫描二维码关注公众号,回复: 8061948 查看本文章



  • 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访问用户授权的资源。

猜你喜欢

转载自www.cnblogs.com/littlerachel/p/11978810.html