的基本流程为:
1、用户访问第三方应用。
2、第三方应用请求用户授权。
3、用户同意授权,并返回一个凭证(code)。
4、第三方应用通过第二步的凭证(code)向授权服务器请求授权。
5、授权服务器验证凭证(code)通过后,同意授权,并返回一个资源访问的凭证(Access Token)。
6、第三方应用通过第四步的凭证(Access Token)向资源服务器请求相关资源。
7、资源服务器验证凭证(Access Token)通过后,将第三方应用请求的资源返回。
解释:
在用户授权这一步中,我们将得到一个用户凭证(code),我们的应用可以通过该用户凭证(code)来和授权服务器交换一个资源访问凭证(Access Token)
当用户点击按钮同意授权后,授权服务器将生成一个用户凭证(code),此时授权服务器如何将用户凭证(code)传递给第三方应用呢?
当我们向授权服务器提交应用信息时,通常需要填写一个redirect_uri,当我们引导用户进入授权页面时,也会附带一个redirect_uri的信息(如https://github.com/login/oauth/authorize?client_id=xxx&redirect_uri=http%3A%2F%2Ftianmaying.com%2Foauth%2Fgithub%2Fcallback&state=XXX),当授权服务器验证两个URL一致时,会通知浏览器跳转到redirect_uri,同时,在redirect_uri后附加用户凭证(code)的相关信息,此时,浏览器返回第三方应用同时携带用户凭证(code)的相关信息。授权后访问的redirect_uri如下:
http://tianmaying.com/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX
浏览器端的行为实际上是不安全的,甚至安全凭证的传递都是通过URL直接传递的。但是由于用户凭证(code)不是那么敏感,其他攻击者拿到用户凭证(code)后依然无法获取到相应的用户资源,所以之前的行为是允许的。
要拿到授权服务器的授权,需要以下几个信息:
* client_id 标识第三方应用的id,由授权服务器(Github)在第三方应用提交时颁发给第三方应用
* client_secret 第三方应用和授权服务器之间的安全凭证,由授权服务器(Github)在第三方应用提交时颁发给第三方应用
* code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址
* state 由第三方应用给出的随机码
我们看到,上述信息还涉及到第三方应用的安全凭证(client_secret),因此要求OAuth要求该请求必须时POST请求,同时,还必须时HTTPS服务,以此保证获取到的验证凭证(Access Token)的安全性。
拿到验证凭证(Access Token)后,剩下的事情就很简单了,资源服务器会提供一系列关于用户资源的API,拿验证凭证(Access Token)访问相应的API即可