1 Introduction
Welcome to Spring Security combat dry goods series. OAuth2.0 is more popular in recent years, authorization mechanisms, for ordinary users may be a day you are using it, we often use third-party login largely based OAuth2.0 . With mutual calls between application interoperability, personalized service, open authentication and authorization needs to be objective.
2. OAuth2.0 simple understanding of
OAuth defines the following roles and a clear distinction between their respective point of interest, in order to ensure consistency of authorization to quickly build service:
- Resource Owner resource owner, refers generally to the end user, granting or denying the effect is even selective authorization request to a third-party applications.
- User Agent User Agent refers to the number of channel resources authorized owner. Generally it refers to the browser, APP
- Client request authorization and request access to restricted resources of the client program.
- Authorization Server server authorization response to the user identification and authorization approved or denied based on the result of discrimination.
- Resource Server can accept and respond to the protected server resource requests.
A simple text description is not somewhat difficult to understand. So I am here to tell stories to a personal experience above the scene of the four concepts. Immediately to the programmer concentrate season interview, the year I went to the interview, to the place only to find such a "big up", visitors need a verification code to come through the gate, so I contacted the interview the company's HR, back flow about Is such that:
- I sent a request to interview the door of the company (HR).
- HR gave me a link to the door can get permission request.
- I conducted door license request via a link.
- Acknowledgment and a verification code back to me.
- I enter this code in the gate program.
- After verification by the release.
I learned OAuth2.0 after the agreement I have found this experience may reflect OAuth2.0 some design ideas. Visitors have access to the building through authorized. This approach avoids unauthorized persons access to office space, but also for visitors controlled (from the access time and frequency) can be achieved even controlled access to the floor (of course, the above example is not).
Combined OAuth2.0 know visitors is the Client, the company (the owners) is the Resource Owner, property is the Authorization Server, the gates is the Resource Server, gates, there may also be subject to control property . This is a well-known flowchart goes:
This example just to fast to know OAuth2.0 , it is an effective and reliable framework for delegation of authority. It offers a variety of licensing models to choose from in different scenarios.
3. Licensing Model
In order to obtain access permissions, the client needs to present a valid certificate of authorization to the authorization server, that client must obtain user authorization ( the Authorization Grant ) OAuth2.0 offers a variety of licensing models for developers to use in different scenarios, the following some summary licensing mode:
| Authorization | Client type / use cases |
|---|---|
| Authorization code | Intended for traditional Web applications and back-end of the machine (mobile or desktop) applications to take advantage of single sign-on through the system browser. |
| Implicit | Apply (JavaScript) application without a back-end browser-based. |
| Password | For application and authorization server belonging to the same provider trusted Native Client. |
| Client credentials | 客户端以自己的名义来获取许可，而不是以终端用户名义，或者可以说该用户端也是资源拥有者 |
| Refresh token | 令牌失效后使客户端可以刷新其访问令牌，而不必再次执行代码或 密码授予的步骤。 |
| SAML 2.0 bearer | 使拥有SAML 2.0断言（登录令牌）的客户端将其交换为OAuth 2.0访问令牌。 |
| JWT bearer | 拥有一个安全域中的JSON Web令牌断言的客户端将其交换为另一域中的OAuth 2.0访问令牌。 |
| Device code | 设备的唯一编码，一般该编码不可更改，多用于一些智能设备 |
| Token exchange | 使用代理模拟的方式获取令牌 |
其中前五种为我们所熟知。我们后续会详细介绍它们。
4. OAuth 2.0 的一些要点
摘自《OAuth 2 实战》：
由于 OAuth2.0 被定义为一个框架，对于 OAuth2.0 是什么和不是什么，一直未明确。我们所说的 OAuth2.0 是指 OAuth2.0 核心规范中定义的协议，RFC 6749 核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的 bearer 令牌，RFC 6750该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是 OAuth2.0 的基本要素。正如我们将在本节中看到的，在更广泛的 OAuth2.0 生态系统中存在很多其他技术，它们配合 OAuth2.0 核心，提供更多 OAuth2.0 本身不能提供的功能。我们认为，这样的生态系统是协议健康发展的体现，但是不应与协议本身混为一谈。
基于以上的原则 OAuth2.0 有以下一些要点需要明确被认识到：
- OAuth2.0 并非身份认证协议，虽然在授权的过程中涉及到身份认证，但是 OAuth2.0 协议本身并不处理用户的信息。客户端访问受保护的资源时并不关心资源的拥有者。
- OAuth2.0 不提供一些消息签名，为了保证安全性所以不应脱离 Https 。在使用其它协议或者系统时也应该明确一个安全机制来承担 Https 所承担的任务。
- OAuth2.0 并没有定义加密方式，虽然目前使用的较多的是 JOSE 规范
- OAuth2.0 虽然令牌被客户端持有并使用，但是客户端并不能解析以及处理令牌。
5. 总结
OAuth2.0 其实还有个特点，它并不是单体协议。它被分成了多个定义和流程，每个定义和流程都有各自的应用场景。所以本文的目的在于场景化的引入 OAuth2.0，当你渐入佳境时，我们再来进行细节的探讨吧。如果你想知道更多关于 OAuth2.0 协议的相关知识，可关注公众号：Felordcn 回复 oauth 获取相关知识的资料。