OAuth2案例应用（附参考开源代码）
目录
OAuth2授权认证中心架构
传统单体应用架构应用安全：
微服务应用架构应用安全：
微服务架构应用安全：
OAuth 2.0主要角色
令牌 (Tokens)
令牌类型：
授权码模式分析：
4.1. Authorization Code Grant
刷新令牌：
四种OAuth 2.0授权类型(Flows)
授权码Authorization Code
简化Implicit
用户名密码Resource Owner Credentials
客户端凭证Client Credentials
授权类型选择
JWT(JSON Web Token)令牌
常见OAuth 2.0安全问题
CSRF令牌劫持
重定向时泄露授权码或者令牌
通过切换客户劫持Token
OpenId Connect
由于系统业务需要，了解OAauth2原理并实现。
OAuth2授权认证中心架构
传统单体应用架构应用安全：
微服务应用架构应用安全：
微服务架构应用安全：
OAuth 2.0主要角色
客户应用 (Client Application) ：通常是一个Web 或者无线应用， 它需要访问用户 的受保护资源
资源服务器 (Resource Server) ：是一个web站点 或者web service API，用户的受保 护数据保存于此
授权服务器 (Authorized Server) ：在客户应用成功 认证并获得授权 之后，向客户应 用颁发访问令牌 Access Token
资源拥有者 (Resource Owner) ：资源的拥有人， 想要分享某些资 源给第三方应用
令牌 (Tokens)
授权服务器在接收到客户请求后，颁发的访问令牌。
令牌类型：
1. 授权码(Authorization Code Token) ：仅用于授权码授权类型，用于交 换获取访问令牌和刷新令牌 。
2. 刷新令牌(Refresh Token) ：用于去授权服务器获取一个新的访问令牌
3. 访问令牌(Access Token) ：用于代表一个用户或服务直接去访问受保护的资源
4. Bearer Token ：不管谁拿到Token都可以 访问资源，像现钞
5. Proof of Possession(PoP) Token 可以校验client是否对Token 有明确的拥有权
授权码模式分析：
这种形式使用范围最广：
https://tools.ietf.org/html/rfc6749#
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
授权代码授予类型用于获取访问令牌和刷新令牌，并针对机密客户端进行了优化。由于这是基于重定向的流，客户端必须能够与资源所有者的用户代理(通常是web浏览器)交互，并且能够接收来自授权服务器的传入请求(通过重定向)。
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
The flow illustrated in Figure 3 includes the following steps:
(A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
(D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
(E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
它的步骤如下：
（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
刷新令牌：
https://tools.ietf.org/html/rfc6749#
1.5 Refresh Tocken
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1).
A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
刷新令牌是用于获取访问令牌的凭据。刷新令牌授权发布到客户机的服务器,用于获得一个新的访问令牌时,当前的访问令牌变得无效或过期,或获得额外的访问令牌相同或窄范围(访问令牌可能生存期较短,和更少的比资源所有者授权的权限)。发出刷新令牌是可选的，由授权服务器决定。如果授权服务器发出刷新令牌，则在发出访问令牌(即，步骤(D)见图1)。
刷新令牌是一个字符串，表示资源所有者授予客户机的授权。字符串对客户端通常是不透明的。令牌表示用于检索授权信息的标识符。与访问令牌不同，refresh令牌仅用于授权服务器，从不发送到资源服务器。
四种OAuth 2.0授权类型(Flows)
授权码Authorization Code
- 通过前端渠道客户获取授权码
- 通过后端渠道，客户使用authorizationcode去交换access Token和可选的refresh token
- 假定资源拥有者和客户在不同的设备上
- 最安全的流程，因为令牌不会传递经过user-agent
简化Implicit
适用于公开的浏览器单页应用
Access Token直接从授权服务器返回 (只有前端渠道)
不支持refresh tokens 假定资源所有者和公开客户应用在同一 个设备上
最容易受安全攻击
用户名密码Resource Owner Credentials
使用用户名密码登录的应用，例如桌面 App
使用用户名/密码作为授权方式从授权服 务器上获取access token
一般不支持refresh tokens
假定资源拥有者和公开客户在相同设备上
客户端凭证Client Credentials
适用于服务器间通信场景，机密客户代 表它自己或者一个用户
只有后端渠道，使用客户凭证获取一个 access token
因为客户凭证可以使用对称或者非对称加密，该方式支持共享密码或者证书
授权类型选择
JWT(JSON Web Token)令牌
JWT令牌分为三部分（三种颜色）
可通过https://jwt.io/ 的 Debugger解析。
常见OAuth 2.0安全问题
CSRF令牌劫持
使用带state参数的CSRF token以确保OAuth flow的一致性
重定向时泄露授权码或者令牌
明确注册重定向URIs，并确保URI验证
通过切换客户劫持Token
将同一客户和授权方式/token 请求进行绑定
OpenId Connect
规范参考：https://oauth.net/ https://openid.net/ https://jwt.io/
授权码模式 参考资料：https://tools.ietf.org/html/rfc6749#section-1.1
Spring Security OAuth2架构 ：http://terasolunaorg.github.io/guideline/5.3.0.RELEASE/en/Security/OAuth.html
阮一峰:理解OAuth 2.0 ：http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
参考开源代码
OAuth2全家桶项目
https://github.com/newnil/oauth2-family-barrel
Apache Oltu+Shiro实现OAuth2服务器(李胜钊)
https://github.com/monkeyk/oauth2-shiro
Using JWT with Spring Security OAuth
https://www.baeldung.com/spring-security-oauth-jwt
https://github.com/Baeldung/spring-security-oauth