背景
哲学上经常有一句话被提到：存在的就是合理的。那么OAuth2.0为什么诞生了呢？我想以我司的一些实际情况来说明。在我司，有很多的内部系统诸如remine系统，工单系统，发布平台系统，会议室预订系统等等。那么如果每一个系统都需要一个账号密码，那么就我想到的至少存在俩个的弊端：其一，每一个系统都需要存储一套用户的账号密码;其二,其实这种操作对于用户来说是繁琐的,是不人性化的。所以，聪明的前辈就有了这样的一个设想：可不可以做一个平台，使任意用户可以在这个平台上注册了一个帐号以后，随后这个帐号和密码自动登记到这个平台中作为公共帐号，使用这个账号可以访问其它的已经授权访问的系统。在这种背景下，OAuth2.0协议就诞生了。
OAuth2.0介绍
目录
OAuth2.0角色设定
OAuth2.0授权流程
OAuth2.0的access token存在的必要性分析
OAuth2.0角色设定
OAuth定义了四个角色。首先我们看一下OAuth2.0官方文档定义的四个角色：
1. Resource owner (the user)：The OAuth 2.0 spec refers to the user as the “resource owner.” The resource owner is the person who is giving access to some portion of their account. The resources in this case can be data (photos, documents, contacts), services (posting a blog entry, transferring funds), or any other resource requiring access restrictions. Any system that wants to act on behalf of the user must first get permission from them.
2. Resource server (the API)：The spec refers to what you typically think of as the main API as the “resource server.” The resource server is the server that contains the user’s information that is being accessed by the third-party application. The resource server must be able to accept and validate access tokens and grant the request if the user has allowed it. The resource server does not necessarily need to know about applications.
3. Authorization server (can be the same server as the API)：The authorization server is what the user interacts with when an application is requesting access to their account. This is the server that displays the OAuth prompt, and where the user approves or denies the access request. The authorization server is also responsible for granting access token after the user authorizes the application. As such, the authorization server will typically have two primary URLs, one for the authorization request and one for applications to use to grant access tokens.
4. Client (the third-party app)：The client is the app that is attempting to act on the user’s behalf or access the user’s resources. Before the client can access the user’s account, it needs to obtain permission. The client will obtain permission by either directing the user to the authorization server, or by asserting permission directly with the authorization server without interaction by the user.
现在请允许我用我的渣渣英语来翻译一下：
1. 资源拥有者:指的是一个可以授权访问被保护资源的个体。
2. 资源服务器:指的是存储被保护资源的服务器，这些资源可以包括视频，相片，用户信息等等。
3. 认证服务器：在资源拥有者授权后,向客户端授权(颁发 access token)的服务器。
4. 客户端：指的是利用资源拥有者的授权信息去请求被保护资源的应用程序,例如第三方服务机构。
OAuth2.0授权流程
老大常说，一图胜千言，一表胜千言。好，我们先睹为快。
接下来，我再对每一步作一些必要的说明。
step1:client 预先在authorization server注册,获得client_id。
step 2:client 向 resource owner 请求授权。client 可以直接向 resource owner 申请授权(如图)，但更好的做法是经由 authorization server 中转授权请求。请求授权的url。如下：
https://authorization-server.com/auth?response_type=code
&client_id=29352735982374239857
&redirect_uri=https://example-app.com/callback
&scope=create+delete
&state=xcoivjuywkdkhvusuye3kchstep 3:resource owner需要对该client 进行身份验证后，resource owner同意给予client 授权authorizationCode,然后回调redirecturi。
step 4:client 使用上一步获得的授权的authorizationCode,向authorization server申请令牌access token。请求授权的url。如下：
POST /oauth/token HTTP/1.1
Host: authorization-server.com
grant_type=authorization_code
&code=xxxxxxxxxxx
&redirect_uri=https://example-app.com/redirect
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
step 5:authorization server对client 进行认证后,同意发放令牌access token。
step 6:client 使用令牌access token,向resource owner申请资源。
step 7:resource owner确认令牌,并向client 开放资源。
OAuth2.0的access token存在的必要性分析
为什么不直接返回 access token，而是返回一个 authorizationCode，再用 authorizationCode 去换 access token 捏？这是不是有点多此一举？
答案是为了 token 的安全，url 回调是 authorization server 给 浏览器一个 302 重定向实现的，所以在浏览器地址栏就可以看到这个code,如果用这种方式返回 token，其实就是掩耳盗铃，所有的秘密都已经一览无余了，还有什么安全性可言呢?所以在 url 上直接返回 access token 是不安全的，而client拿到authorizationCode以后换取access token是client后台对认证服务器的访问，不依赖浏览器，并且需要client_id和client_secret，client_id和client_secret是在authorization server 上注册时产生的，access token不会暴露出去。
感谢&总结
本文主要分析了OAuth2.0的认证流程。"日拱一卒无有尽 功不唐捐终入海",每天进步一点点，量变引起质变，最后，我们还是可以取得长足的进步的，共勉。