Oauth2个人学习记录（一）

前言
前段时间公司给了个机会断断续续地学习SpringCloud，并且找了个搭好的简洁Demo，里面有个Auth服务用到了Oauth2，为了个灵活的操作这个微服务Demo，我打算熟悉一下这个Oauth2组件。
博主的学习资源

初识Oauth2

概念走一波

OAuth 2.0是目前最流行的授权机制，用来授权第三方应用，获取用户数据。
OAuth（开放授权）是一个关于授权的开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息（比如照片、视频、用户信息等），而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0。即完全废止了OAuth1.0。OAuth 2.0协议正式发布为RFC-6749。
OAuth2主要包含以下特点：

• 用于REST/APIs的代理授权框架(delegated authorization framework)
• 基于令牌Token的授权, 在无需暴露用户密码的情况下,使应用能获取用户数据的有限访问权限
• 解耦认证和授权
• 事实上的标准安全框架,支持多种用例场景：
  • 服务器端WebApp
  • 浏览器单页SPA
  • 无线/原生App
  • 服务器对服务器之间

Oauth2的工作原理

首先，常规的应用向资源服务器请求资源，只需要一个Http Request。
然后，第三方应用想要获取我微信的用户名和一些用户数据，那么微信必定不能把我的微信账号和密码发给第三方应用，然后就出现了指令（access token）作为授权码。
OAuth2整体流程图：

总结就是：第三方应用向授权服务器请求Access Token —> 授权服务器向我征询意见，是否将权限授予客户应用 —> 我同意 —> 授权服务器生成Access Token给第三方应用 —> 第三方应用拿着Access Token去请求资源服务器 —> 资源服务器验证第三方应用的Access Token —> 验证通过，返回我的微信名~

进入正题

相传Oauth2有四种模式，各个模式有对应的使用场景：

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

第一式 授权码模式 authorization code

秘籍说到授权码模式是功能最完整、使用最广泛、流程最严密的授权模式。
指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
仔细看一遍也就那么来来去去的几招了，本弟子画了个图：

第二式 简化模式 implicit

简化模式 不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

直接上图：

第三式 密码模式 resource owner password credentials

密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

第四式 客户端模式 client credentials

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
执行流程跟密码模式几乎一样，只是密码不是由用户提供。

版权声明：文章内容总结于网络，如侵犯到原作者权益，请与我联系删除或授权事宜