示例¶
0. 访问登陆页面¶
当用户希望使用第三方登录进行登录时,第三方应用会通过类似下图 “快速登陆图标” 的方式将用户引导至授权页面,为了和 OAuth 基本流程一致,我们将这一步定义为第 0 步。
【用户身份验证】当我们点击 Github 的图标,我们会进入到 Github 应用下面,此时实际上进行了一次用户身份的验证,之前没有登录 Github 的用户需要输入 Github 的账号密码,已登录的用户 Github 会根据 Session 进行身份确认。
1. 用户授权¶
用户身份确认后会进入下面这个页面,该页面由授权服务器提供,授权服务器会告诉用户该第三方在授权服务器中提交的相关信息(如果需要实现第三方登录功能,第三方应用需要向 Github、微博等应用中提交应用的相关信息,不同服务可能会需要审核等不同的步骤),以及授权后第三方应用能够获取哪些资源。
在 Github 中,最基础的认证可以访问用户的公共信息。如果用户同意授权,需要主动的点击【Authorize application】按钮。
2. 返回用户凭证(code)¶
当用户点击按钮同意授权后,授权服务器将生成一个用户凭证(code),此时授权服务器如何将用户凭证(code)传递给第三方应用呢?
当我们向授权服务器提交应用信息时,通常需要填写一个 redirect_uri
当我们引导用户进入授权页面时,也会附带一个 redirect_uri 的信息(如 Sign in to GitHub · GitHub)
当授权服务器验证两个 URL 一致时,会通知浏览器跳转到 redirect_uri,同时,在 redirect_uri 后附加用户凭证(code)的相关信息,此时,浏览器返回第三方应用同时携带用户凭证(code)的相关信息。授权后访问的 redirect_uri 为:https://www.csdn.net/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX
3. 请求授权服务器授权¶
从这一步开始,OAuth2 的授权将有两个重大变化的发生:
用户主动行为结束,用户理论上可以不需要再做任何主动的操作,作为第三方应用的我们可以在后台拿到资源服务器上的资源而对用户是不可见的,当用户的浏览器跳到下一个页面时,整个 OAuth2 的流程已经结束
浏览器端行为结束,从 OAuth2 的基本流程可以看出,接下来的流程已经不需要和用户进行交互,接下来的行为都在第三方应用与授权服务器、资源服务器之间的交互。
要拿到授权服务器的授权,需要以下几个信息:
client_id 标识第三方应用的 id,由授权服务器(Github)在第三方应用提交时颁发给第三方应用 client_secret 第三方应用和授权服务器之间的安全凭证,由授权服务器(Github)在第三方应用提交时颁发给第三方应用 code 第一步中返回的用户凭证 redirect_uri 第一步生成用户凭证后跳转到第二步时的地址 state 由第三方应用给出的随机码
4. 返回访问凭证 Access Token¶
当授权服务器拿到第 3 步中的所有信息,验证通过后,会将 Access Token 返回给第三方应用。
5. 向资源服务器请求相关资源¶
拿到验证凭证(Access Token)后,资源服务器会提供一系列关于用户资源的 API,拿验证凭证(Access Token)访问相应的 API 即可
注意,此时的访问不是通过浏览器进行的,而是服务器直接发送 HTTP 请求,因此其安全性是可以保证的。
6. 返回资源¶
如果验证凭证(Access Token)是正确的,此时资源服务器就会返回资源信息,此时整个 OAuth 流程就结束了