Outline
The purpose of this section is to help you quickly get started with Spring Security oAuth2 Spring offered to build a resource access verification and authorization services to help everyone in the micro-enterprise services architecture can effectively control multiple services unified login, authorization and resource protection work
what is oAuth
oAuth protocol provides a secure authorized user resources, open but simple standard. Conventional License difference is not authorized oAuth the account information to a third party touch (such as user names and passwords) of users, that is, without the use of third-party user name and password that the user can apply for resources Authorizations, oAuth is safe.
What is the Security Spring
Spring Security a security framework, formerly known as Acegi Security, to provide secure access control for the Spring declarative enterprise applications. Spring Security Servlet-based filters, and the AOP the IoC, and a method for providing Web requests for the call identification and authorization processing code coupled avoided, reduced the amount of code duplication of work.
Why oAuth2
Scenario
we assume that you have a "cloud notes" products, and provide a "cloud note-taking service" and "cloud album service" where users need different devices (PC, Android, iPhone, TV , Watch) up access to these "resources" (notes, pictures)
So how users can access some of the resources that belong to them then? At this time, the traditional approach is to provide their account number and password to our "cloud notes," after a successful login can get the resources. But such an approach will have the following questions:
"Cloud note-taking service" and "cloud album service" will be deployed respectively, are we going to log difference?
If you have a third-party application wants to access our "cloud notes," Do not require the user to provide account and password to third-party applications, let him record it and then access our resources?
How user limit third-party applications in our "cloud notes," the mandate and period of use? Is all the information are permanently exposed to it do?
If you changed the password to recover the permissions, then all third-party applications will all fail.
As long as there is access to a third-party applications have been cracked, then the user's password is compromised, the consequences could be disastrous.
In order to solve the above problems, oAuth application for us.
Glossary
third-party application (the Application Third-Party) : also known as Client (client), equipment (PC, Android, iPhone, TV , Watch) such as mentioned in the previous section, we will be installed in these devices our own research and development of APP. Another example of our products you want to use a third-party login QQ, micro letters. Our product is, QQ, micro-channel to log a third-party registration system. We need a third-party sign-on system resources (avatar, nickname, etc.). For QQ, micro letters and other systems, we are also third-party applications.
HTTP Service Provider (HTTP Service) : Our cloud notes and product QQ, micro-channel and so can be called "service providers."
The resource owner (Resource Owner) : also known as user (user).
User Agent (the User Agent) : such as the browser, instead of the user to access these resources.
The authentication server (Authorization server): The ISP server designed to handle authentication, simple point that is the login function (verify the user's account password is correct and assign the appropriate permissions)
resource server (Server Resource) : the service provider to store user-generated resource server. It authentication server, which can be the same server, it can be a different server. Simply put, it is the entrance to access resources, such as the section mentioned in the "cloud note-taking service" and "cloud album service" can be called the resource server.
Interaction
oAuth between the "client" and "service providers", set up a layer of authorization (authorization layer). "Client" can not log in directly to "service providers" can only login authorization layer, in order to distinguish between the user and the client area. "Client" Registration Authority layer with tokens (token), and passwords for different users. Users can login time, specify the authorization token layer of competence and validity. After the "client" login authorization layer, "Service Provider" under the authority of the scope and validity of the token to the "client" user data stored in the open.
Open Platform
Interaction model
interaction model involves three parties:
Resource Owner: User
Client: APP
service provider: contains two roles
authentication server
resource server
authentication server
authentication server is responsible for authenticating the user, and the permissions granted to the client. Certification is easy to implement (verified account password), the question is how authorization. For example, we use third-party log on "Ethics cloud notes," As you can see there on the authorized use of QQ login page "Ethics cloud notes will receive the following privileges" in the words and the right information
authentication server needs to know the client's request authorization the identity and rights of the client request. We can end for each client a pre-assigned id, and corresponds to a name and the right information to each id. This information can be written in a configuration file on the server where the certification. The client then every time you open authorization page when the id pass over their own, such as:
http://www.funtl.com/login?client_id=yourClientId
Over and business growth over time, you will find, modify the configuration work consumes too much manpower. Is there a way to automate this process up, to liberate from the tedious manual operations? When you start to consider this step, forming an open platform that is a natural thing.
oAuth2 open platform
open platform is derived from the agreement oAuth2.0 a product. Its role is to allow clients to register themselves to apply this above, after the adoption of the system automatically assigns client_id, automatic update and complete the configuration (usually written into the database).
Client To complete the application, usually need to fill out the type of client programs (Web, App, etc.), business description, licenses, permissions, and so want to get information. After getting the information service provider by manual review, development platform will automatically assign a client_id to the client.
Here, we have achieved a login authentication, authorization information presentation page. So then, after a user successful authorization, authentication server needs to send access_token produced to the client program are as follows:
让客户端在开放平台申请的时候，填写一个 URL，例如：http://www.funtl.com
每次当有用户授权成功之后，认证服务器将页面重定向到这个 URL（回调），并带上 access_token，例如：http://www.funtl.com?access_token=123456789
客户端接收到了这个 access_token，而且认证服务器的授权动作已经完成，刚好可以把程序的控制权转交回客户端，由客户端决定接下来向用户展示什么内容
令牌的访问与刷新
Access Token
Access Token 是客户端访问资源服务器的令牌。拥有这个令牌代表着得到用户的授权。然而，这个授权应该是 临时 的，有一定有效期。这是因为，Access Token 在使用的过程中 可能会泄露。给 Access Token 限定一个 较短的有效期 可以降低因 Access Token 泄露而带来的风险。
然而引入了有效期之后，客户端使用起来就不那么方便了。每当 Access Token 过期，客户端就必须重新向用户索要授权。这样用户可能每隔几天，甚至每天都需要进行授权操作。这是一件非常影响用户体验的事情。希望有一种方法，可以避免这种情况。
于是 oAuth2.0 引入了 Refresh Token 机制
Refresh Token
Refresh Token 的作用是用来刷新 Access Token。认证服务器提供一个刷新接口，例如：
http://www.funtl.com/refresh?refresh_token=&client_id=
传入 refresh_token 和 client_id，认证服务器验证通过后，返回一个新的 Access Token。为了安全，oAuth2.0 引入了两个措施：
oAuth2.0 要求，Refresh Token 一定是保存在客户端的服务器上 ，而绝不能存放在狭义的客户端（例如 App、PC 端软件）上。调用 refresh 接口的时候，一定是从服务器到服务器的访问。
oAuth2.0 引入了 client_secret 机制。即每一个 client_id 都对应一个 client_secret。这个 client_secret 会在客户端申请 client_id 时，随 client_id 一起分配给客户端。客户端必须把 client_secret 妥善保管在服务器上，决不能泄露。刷新 Access Token 时，需要验证这个 client_secret。
实际上的刷新接口类似于：
http://www.funtl.com/refresh?refresh_token=&client_id=&client_secret=
以上就是 Refresh Token 机制。Refresh Token 的有效期非常长，会在用户授权时，随 Access Token 一起重定向到回调 URL，传递给客户端。
客户端授权模式
概述
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。oAuth 2.0 定义了四种授权方式。
implicit：简化模式，不推荐使用
authorization code：授权码模式
resource owner password credentials：密码模式
client credentials：客户端模式
简化模式
简化模式适用于纯静态页面应用。所谓纯静态页面应用，也就是应用没有在服务器上执行代码的权限（通常是把代码托管在别人的服务器上），只有前端 JS 代码的控制权。
这种场景下，应用是没有持久化存储的能力的。因此，按照 oAuth2.0 的规定，这种应用是拿不到 Refresh Token 的。其整个授权流程如下：
该模式下，access_token 容易泄露且不可刷新
授权码模式
授权码模式适用于有自己的服务器的应用，它是一个一次性的临时凭证，用来换取 access_token 和 refresh_token。认证服务器提供了一个类似这样的接口：
https://www.funtl.com/exchange?code=&client_id=&client_secret=
需要传入 code、client_id 以及 client_secret。验证通过后，返回 access_token 和 refresh_token。一旦换取成功，code 立即作废，不能再使用第二次。流程图如下：
这个 code 的作用是保护 token 的安全性。上一节说到，简单模式下，token 是不安全的。这是因为在第 4 步当中直接把 token 返回给应用。而这一步容易被拦截、窃听。引入了 code 之后，即使攻击者能够窃取到 code，但是由于他无法获得应用保存在服务器的 client_secret，因此也无法通过 code 换取 token。而第 5 步，为什么不容易被拦截、窃听呢？这是因为，首先，这是一个从服务器到服务器的访问，黑客比较难捕捉到；其次，这个请求通常要求是 https 的实现。即使能窃听到数据包也无法解析出内容。
有了这个 code，token 的安全性大大提高。因此，oAuth2.0 鼓励使用这种方式进行授权，而简单模式则是在不得已情况下才会使用。
密码模式
密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向 “服务商提供商” 索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分。
A typical example is with a different product within the enterprise to use oAuth2.0 system of the enterprise. In some cases, the product can be customized hope authorization page. Because it is a business with no need to show the user "xxx will get the following rights" and other words and ask the user's intention to authorize, but only for user authentication can be. This time, the development of a specific product team customized interface authorized to receive user input account password, and can be passed directly to the authentication server for authorization.
One thing to note is that, in step 2, the authentication server needs to verify the identity of the client to ensure the client is trusted.
Client mode
if a trust relationship further, or if the caller is a back-end module, when there is no user interface, you can use client mode. Authentication server directly to the client to authenticate, after verification by, the return token.
