2024年3月24日发(作者:)

谈谈基于OAuth 2.0的第三方认证 [下篇] - Artech - 博客园/artech/p/

博客园首页新随笔联系

微信账号:Artech1981

蒋金楠(Artech),8任微软MVP(

Solutions Architecture、Connecte

d System、Microsoft Integration

与/IIS)。《WCF技术剖析

》、 《WCF全面解析》、《

MVC 4框架揭秘》、《 We

b API 2框架揭秘》、《 MV

C 5框架揭秘》作者。

MVC 5完全攻

略[《 MVC 5框

架揭秘》繁体版]

MVC 5框架揭

[源代码可以通过360云盘

下载(提取码:c6ec)]

[1] 互动网

[2] 亚马逊

[3] 京东商城

[4] 当当网

第1页 共9页

订阅管理随笔- 555 文章- 2 评论- 22525

谈谈基于OAuth 2.0的第三方认证 [下篇]

从安全的角度来讲,《中篇》介绍的Implicit类型的Authorization Grant存在这样的两个问题:其一,授权服务器没有对客户端

应用进行认证,因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret;其二,Access Toke

n是授权服务器单独颁发给客户端应用的,照理说对于其他人(包括拥有被访问资源的授权者)应该是不可见的。Authorization

Code类型的Authorization Grant很好地解决了这两个问题。

Authorization Code Authorization Grant授权流程

Authorization Code是最为典型的Authorization Grant,它“完

美”地实现了指定的OAuth初衷:资源拥有者可以在向客户端应用

提供自身凭证的前提下授权它获取受保护的资源。如右图所示,A

uthorization Code类型的Authorization Grant具有完整的“三

段式”授权流程,接下来,我们还要针对“集成Windows Live Con

nect认证 获取当前用户个人信息”这个应用场景来讨论一下Autho

rization Code类型的Authorization Grant的具体授权流程。

Implicit类型的Authorization Grant授权的客户端运行于存客户

端(浏览器)上下文环境,Authorization Code类型的Authoriz

ation Grant则适用于运行于服务器的应用,比如 MVC

应用的Controller,或者是定义在View中的服务端程序。右图体现的就是在服务器()运行的客户端应用[1]

上面我们已经说过,Authorization Code类型Authorization Grant具有与Kerberos类似的授权方式。如果我们将Access Toke

n看作为了获取受保护资源而“登堂入室”的入场券的话,Authorization Code就是购买这张入场券的“认购权证”。客户端应用需要

首先取得Authorization Code,因为它代表了资源拥有者对它的授权,并且是获取Access Token时必须提供的凭证。

客户端应用首先向授权服务器发送一个获取Authorization Code的请求,请求的地址同样为“/oauth20

_”,相应的参数同样以查询字符串的形式提供。与Implicit类型Authorization Grant获取Access Token的请求一

样,此时需要提供如下4个完全一样的参数。

response_type:表示请求希望获取的对象类型,在此我们希望获取的是Authorization Code,所以这里指定的值为“c

ode”。

redirect_uri:表示授权服务器在获得用户授权并完成对用户的认证之后重定向的地址,Authorization Code就以查询

字符串(?code={authorizationcode})的方式附加在该URL后面。客户端应用利用这个地址接收Authorization Cod

e。

client_id: 唯一标识被授权客户端应用的ClientID。

scope:表示授权的范围,根据具体需要的权限集而定。

如果当前用户尚未登录但Windows Live Services,他会被自动重定向到登录页面。在尚未对客户端应用进行授权的情况下,如

左图所示的授权页面会显示出来。在取得登录用户的授权之后,授权服务器会返回一个重定向的响应,而请求提供的redirect_uri

参数值直接作为重定向地址。由授权服务器生成的Authorization Code就以查询字符串(?code={authorizationcode})的方

式附加在重定向URL的后面。重定向的请求被客户端应用接收后,Authorization Code被提取并保存起来。

接下来客户端应用会利用得到的Authorization Code向授权服务器获取Access Token,这一般为HTTP-POST请求。作为请求消

息主体传递的内容除了作为参数“code”的Authorization Code之外,还包含如下一些必需的参数。

client_id: 唯一标识被授权客户端应用的ClientID。

70

client_secret:唯一标识被授权客户端应用的ClientSecret。

redirect_uri:之前获取Authorization Code时指定的重定向地址。

(请您对文章做出评价)

2015/07/18 星期六 11:03

谈谈基于OAuth 2.0的第三方认证 [下篇] - Artech - 博客园/artech/p/

Web API 2框

架揭秘[火热销售中 ]

[1] 互动网

[2] 亚马逊

[3] 当当网

[4] 京东商城

[5] 天猫商城

[6] 淘宝网

MVC 4框架揭

[1] 互动网

[2] 亚马逊

[3] 当当网

[4] 京东商城

[5] 苏宁易购

[6] 淘宝网

WCF全面解析

[1] 互动网

[2] 亚马逊

[3] 当当网

[4] 京东商城

[5] 苏宁易购

[6] 淘宝网

第2页 共9页

grant_type:采用的Authorization Grant类型,参数值为“ aut

horization_code”。

授权服务器接受到请求之后,除了利用提供的ClientID和ClientS

ecrete对客户端应用实施验证之外,还会检验之前获取Authoriza

tion Code提供的ClientID和重定向地址是否与本次提供的一致。

成功完成检验之后,授权服务器会生成一个Access Token作为响

应内容发送给客户端应用。整个响应内容除了Access Token之外

,还包含其他一些与之相关的属性。

1: {

2:"token_type":"bearer",

3:"expires_in":3600,

4:"scope":" ",

5:"access_token":"EwAwAq1DBAAUGCCXc8wU/zFu9QnLdZXy+YnElFk

AAUJrhIwUzWhsNUTrrNst0ThiSSQ4633vMMkJVIWC9o7RF5Fbml42RptWs8+fg1pI

WQsroN+0tTB3+uIFtI2ZjWY+E1Fv40WAU7SmvbIJ8CTkxvCSC96ie/kgV0Q+TvYFG

ZYRbXhMwc2pqY2LxWp0DKbSmKWXUmJn5/tf48a8n7HLBjc8fcrWfr1ff99lBSgCri

5AGsEeVWH2/UpkUmVMazfBFqJNdaZyrQ8HmIgWWcfPI3B1mrIRFWprlIMNdF6nERiOExdTcCK6xqM3HhLtwHtqLKXMa0N568hR4xn1FYSXqgAjCWllvJ1BT51g0YDQyg

efL4ynmo7H/2rjPuKS70EDZgAACI4PXp7hCnaKAAGzOZCLbNQd1ucG/bLSEq23hEAFKX9vdmG1IUOVF2X+/tV2G5ZXnj1QL/F2WSW4dOpnU41lUnMZr+hOSq7ljF9d2I

MOyDpHKuzTavUQO6GvxHoPuLMhZGP0kzYye+ASdHT2Ave6cBisSp6e/EIRZDRWyUfuAjg9mk5NKdQlFjQyKLMIiBupLKqJMN3Mdld/R412V3w1JQStB0kM93nV99H4ou

SMq1sj13sJpLhUesnuSK6XfG9RcVo2hioy28qt4SoZxL8kWaQqsgPRpJ4Mkyu6sRYEAmK5olCqN6L/fNzy6fRXELKzfl33H61zkAllzYoxCKuoof0Mm6nANj1SMpI1AA

A=",

6:"authentication_token":"2ZXIiOjEsImlzcyI6InVybjp3aW5kb3dzOmxpdmV

pZCIsImV4cCI6MTM4NTg2MDQ3NiwidWlkIjoiNzY4YjMxYjU3NjFlN2EzMTIzNzk5ZjIzNzFjMDIxOGEiLCJhdWQiOiJ3d3cuYXJ0ZWNoLmNvbSIsInVybjptaWNyb3N

vZnQ6YXBwdXJpIjoiYXBwaWQ6Ly8wMDAwMDAwMDQ4MTBDMzU5IiwidXJuOm1pY3Jvc29mdDphcHBpZCI6IjAwMDAwMDAwNDgxMEMzNTkifQ.2qn4MWtekRhkgLoRyiFo

B5NmUnQ0oKuqQuqpdfb46os"

7: }

授权服务器返回Access Token的完整响应内容如上所示,我们可以看到这是一个以JSON格式表示的对象。除了Access Token

自身的内容之外,还可以获取其他一些相关的信息,比如Access Token的类型(token_type)、过期时间(“expires_in”,单

位为秒)、授权范围(“scope”,与获取Authorization Code时指定的一致)以及表示认证身份的安全令牌(“authentication_t

oken”)。

客户端应用接受到响应之后从中提取出Access Token。当它试图获取受保护资源的时候,将此Access Token附加到请求上,便

会以授权用户的名义得到它所需要的资源。对于我们的应用场景来说,客户端应用直接将Access Token作为请求的查询字符串(

?access_token={accesstoken})访问地址“/v5.0/me”便会成功获取当前登录用户的基本信息。

通过上面对Authorization Code类型的Authorization Grant整个授权流程的介绍,可以看出Implicit Authorization Grant的

两个安全问题得到了很好的解决:虽然客户端获取Authorization Code时不需要指定ClientSecret,但是在获取Access Token

时ClientRecret则是必需的,授权服务器只有在成功验证客户端应用身份的情况下才会颁发Access Token;针对Access Token

的消息交换仅限于授权服务器和客户端应用之间进行,所以第三方(包括 当前用户)都无法获取到正确的Access Token。

Refresh Token

处于安全性考虑,Access Token并非终身有效,而是具有一个过期时间。上面我们给出了授权服务器返回Access Token的响应

内容,其“expires_in”属性表示的就是Access Token的有效期限。那么,Access Token过期之后该如何处理呢?是否需要重新

获得Authorization Code并利用它得到新的Access Token呢?

实际上这是不需要的,当我们得到Authorization Code之后,可以在利用它获取Access Token的时候,让授权服务器一并返回

一个叫做Refresh Token的令牌。与Access Token不同,Refresh Token是一个长期有效的安全令牌,当Access Token过期之

后,我们可以利用它获取一个新的Access Token。

对于Windows Live Connection来说,如果希望在获取Access Token的时候让授权服务器返回一个Refresh Token,其指定的

授权范围必须具有一个名为“e_access”的Scope,它表示允许客户端程序在任何时候(包括用户尚未登录Windows Liv

e Connect的情况下)读取和更新用户信息。对于具有如此授权范围的Access Token请求,授权服务器返回的响应中会按照如下

的形式包含Refresh Code的内容。

1: {

2:"token_type":"bearer",

3:"expires_in":3600,

4:"scope":" e_access",

5:"access_token":"EwAwAq1DBAAUGCCXc8wU/zFu9QnLdZXy+YnElFkAAZcfA2Qg/7KeYyCTe+jx4bLz8qTAFTV71leUhqb0XEfZlRHdi/YpTUx5raBNbd2Tcq

mdPT1p6v7NhZHTvwJg7u+nyEosIIB0hjxDPTEkU8nj6HYZ96OP29Vr6rVbWer5tczd5ez7Hm/GOSTcC2c4w7G1hvoh/wpg26Gn/ox5P0dE

GS0kYOr3MUgH5JMe+ObuoEQavJtxSnXjhr6Vh9Oe8TSAtmsy32f3LMnf/B/8rQHxmGd284OPQlBgH8hy5z0NsrSS6B/4oMFU+oZSYwWaHM

5Zg0qw2KHLy9eMw2a3wz4DZgAACCEjkTQbxjh/AAHTGE/O2koIChcvaQbkt0DQq+lMxtjp0U8rWABcwTz89Vy7zIlz8l9hzAewpiM+W/6O

70

FJbmZ571NPXMI6p7l1uoUR3yPzDBOOKQn5fGeMmyMjZZsMnjQAzm+JxVoLRFnlwZJeTe4BA0x6bAOb/j4T+Nk6I1nTKMuTvFztluWw4oRT

4Khc+tiSIeRDMl4mEpHzlSj2iEhzokfIjqaLq1iPW4EQKXYh3i+o44RjZ4effY4jFAe1jtaojRHVZrtq8g6x06LswECPHhH91i2oD8SMza

A=",

(请您对文章做出评价)

6:"refresh_token":"CgnjZWSPqffDqDkt3NeqFHwMKs7xiwpM2gQx0A8WOGbIAPbAXqJAZOB1lhcEV8BOWvZevk5Uo9hUu*lEa8TKXRiw*V8KE8!jhEOMQ9o*u

2015/07/18 星期六 11:03