如何规避电子政务门户网站建设教训,上海的公司名称,浙江省住房城乡建设厅官方网站,php网站首页模板0. RFC6749还有哪些可以完善的#xff1f;
0.1. 撤销Token
在上篇[认证授权] 1.OAuth2授权 中介绍到了OAuth2可以帮我们解决第三方Client访问受保护资源的问题#xff0c;但是只提供了如何获得access_token#xff0c;并未说明怎么来撤销一个access_token。关于这部分OAut…0. RFC6749还有哪些可以完善的
0.1. 撤销Token
在上篇[认证授权] 1.OAuth2授权 中介绍到了OAuth2可以帮我们解决第三方Client访问受保护资源的问题但是只提供了如何获得access_token并未说明怎么来撤销一个access_token。关于这部分OAuth2单独定义了一个RFC7009 - OAuth 2.0 Token Revocation来解决撤销Token问题。
0.2. Token对Client的不透明问题
OAuth2提供的“access_token是一个对Client不透明的字符串尽管有scopeexpires_in和refresh_token来辅助但也是不完善的且分散的信息。还拿上一篇的小明来举例“小明授权在线打印并且包邮的网站访问自己的QQ空间的相册”。双引号里面的这句话其中有4个重要的概念
授权者小明表示是小明授权而不是隔壁老王。被授权者在线打印并且包邮的网站表示授权给指定的网站而不是其他的比如1024.com之类的网站你懂的。。。。小明自己的QQ空间表示让被授权者访问自己的信息而不是隔壁老王的信息小明也没这权限来着不然隔壁王婶夜不答应吧。。。相册表示你可以访问我的相册而不是我的日志我的其他信息。
那么如何得到获得上面提到的这些附加的信息呢?OAuth2又单独提供了一个RFC7662 -OAuth 2.0 Token Introspection来解决Token的描述信息不完整的问题。
1. OAuth2 Token 撤销RFC7009 - OAuth2 Token Revocation
简单来说这个协议规定了一个Authorization server提供一个怎样的API来供Client撤销access_token或者refresh_token。
比如Client发起一个如下的请求 POST /revoke HTTP/1.1Host: server.example.comContent-Type: application/x-www-form-urlencodedAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWtoken45ghiukldjahdnhzdauztoken_type_hintrefresh_token 其中各项含义如下
/revoke是Authorization Server需要提供的API地址Client使用Post方式请求这个地址。Content-Type: application/x-www-form-urlencoded固定此格式。Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW访问受保护资源的授权凭证。token必选可以是access_token或者refresh_token的内容。token_type_hint可选表示token的类型值为”access_token“或者refresh_token。
如果撤销成功则返回一个HTTP status code为200的响应就可以了。
2. OAuth2 Token 元数据RFC7662 - OAuth2 Token Introspection
简单的总结来说这个规范是为OAuth2扩展了一个API接口Introspection Endpoint让第三方Client可以查询上面提到的那些信息比如access_token是否还有效谁颁发的颁发给谁的scope又哪些等等的元数据信息。
比如Client发起一个如下的请求 POST /introspect HTTP/1.1Host: server.example.comAccept: application/jsonContent-Type: application/x-www-form-urlencodedAuthorization: Bearer 23410913-abewfq.123483token2YotnFZFEjr1zCsicMWpAAtoken_type_hintaccess_token 看起来和上面的撤销Token的请求差不多其中各项含义如下
/introspect是Authorization Server需要提供的API地址Client使用Post方式请求这个地址。Accept:application/json表示Authorization Server需要返回一个JSON格式的数据。Content-Type: application/x-www-form-urlencoded固定此格式。Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW访问受保护资源的授权凭证。token必选可以是access_token或者refresh_token的内容。token_type_hint可选表示token的类型值为”access_token“或者refresh_token。
如果请求成功则会返回如下的信息
{ active: true, client_id: l238j323ds-23ij4, token_type:access_token, username: jdoe, scope: read write dolphin, sub: Z5O3upPC88QrAjx00dis, aud: https://protected.example.net/resource, iss: https://server.example.com/, exp: 1419356238, iat: 1419350238, nbf: 1419350238, jti: abcdefg extension_field: twenty-seven
}
JSON各项属性含义如下其中有些信息是在JSON Web Token中定义的参考链接有详细的介绍:
active必须的。表示token是否还是有效的。client_id可选的。表示token所属的Client。比如上面的在线打印并且包邮的网站。token_type可选的。表示token的类型。对应传递的token_type_hint。user_name可选的。表示token的授权者的名字。比如上面的小明。scope可选的。和上篇5.1.1 Authorization Request中的可选参数scope对应表示授权给Client访问的范围比如是相册而不是小明的日志以及其他受保护资源。sub可选的。token所属的资源拥有者的唯一标识JWT定义的。也就是小明的唯一标识符。aud可选的。token颁发给谁的JWT定义的。iss可选的。token的颁发者JWT定义的。exp可选的。token的过期时间JWT定义的。iat可选的。iss颁发token的时间JWT定义的。nbf可选的。token不会在这个时间之前被使用JWT定义的。jti可选的。token的唯一标识JWT定义的。extension_field可以自己扩展相关其他属性。
其中大量的信息都是可选的信息而且可以自己扩展需要的属性信息从这些属性中就可以解决我们上面提到的access_token对于Client不透明的问题。
我们注意到其中有很多属于JWT定义的属性那么这个JWT是什么东西它解决了什么问题
3. JSON Web Token (JWT)
简单总结来说JWT是一个定义一种紧凑的自描述的并且提供防篡改机制的传递数据的方式的标准协议。
我们先来看一个简单的示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Imxpbmlhbmh1aSJ9.hnOfZb95jFwQsYj3qlgFbUu1rKpfTE6AzgXZidEGGTk
就是这么一堆看起来像是乱码一样的字符串。JWT由3部分构成header.payload.signature每个部分由“.”来分割开来。
3.1. Header
header是一个有效的JSON其中通常包含了两部分token类型和加密算法。
{alg: HS256,typ: JWT
}
对这个JSON采用base64编码后就是第1部分eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。
3.2. Payload
这一部分代表真正想要传递的数据包含一组Claims其中JWT预定义了一些Claim2. Token 元数据 这一节就用到一些JWT预定义的一些Cliam后面会介绍。关于什么是Claim可以参考文章末尾给的参考链接。
{sub: 1234567890,name: linianhui
}
对这个JSON采用base64编码后就是第2部分eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Imxpbmlhbmh1aSJ9。
3.3. Signature
这一部分是可选的由于前面Header和Payload部分是明文的信息所以这一部分的意义在于保障信息不被篡改用的生成这部分的方式如下
HMACSHA256(base64UrlEncode(header) . base64UrlEncode(payload),secret)
使用header中指定的签名算法对“header.payload”部分进行签名得到的第3部分hnOfZb95jFwQsYj3qlgFbUu1rKpfTE6AzgXZidEGGTk。然后组合成一个完整的JWT字符串而接收方使用同样的签名算法来生成签名来判断header和payload部分有没有被篡改锅因为签名的密钥是只有通信双方知道的所以可以保证这部分信息不被第三方所篡改。
3.4. JWT的一些Claims
JWT规范中预先定义了一些Cliam但并不是必选的常用的有
issIssuer签发者。subsubject签发给的受众在Issuer范围内是唯一的。audAudience接收方。expExpiration Time过期时间。iatIssued At签发时间等等。
更完整的一些Claim列表参见https://www.iana.org/assignments/jwt/jwt.xhtml
如果上面这些仍无法满足自己的需要则可以自定义一些来使用。
3.5. JWT 应用场景
由于其采用base64来进行编码使得它可以安全的用在一些仅限ASCII的地方传递信息比如URL的querystring中。
比如用户登陆后可以把用户的一些属性信息用户标识是否是管理员权限有哪些等等可以公开的信息用JWT编码存储在cookie中由于其自描述的性质每次服务器读取到Cookie的时候就可以解析到当前用户对应的属性信息而不必再次去查询数据库。如果Cookie中每次都发送浪费带宽也可以用 Authorization: Bearer jwttoken 的方式附加到Request上去。
4. OAuth2 JWT
注意到我们在2. Token 元数据 这一小节中OAuth2返回Token的元数据的JSON以及OAuth2中的access_token对Client是不透明的字符串这件事我们可以把access_token的元数据信息用JWT来编码以下作为access_token的字符串内容这样是不是就可以使得它对Client是透明的了。
比如我之前遇到的问题在我使用access_token的时候有没有过期我并不知道其实需要借助辅助的“expires_in”来检查还有其scope是哪些也需要额外的去查询再比如这个access_token管理的用户是谁也需要额外的查询有了JWT呢可以把这些都打包进去比如
{ sub:linianhui, scope:1419356238, exp:123456789,
}
然后生成一个这样的jwt字符串 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJsaW5pYW5odWkiLCJzY29wZSI6IjE0MTkzNTYyMzgiLCJleHAiOjEyMzQ1Njc4OX0.ASu85ohHMSOhnxbJSJI4OKLsPlbjPs7th0Xw5-b4l1A 作为access_token的值感觉一下子就方便了好多吧。
5. 总结
OAuth2在RFC6749中并未完整的提供一些问题的解决方案而是附加了一些相关的RFC来解决这些问题其实除了本文中提到的2个问题点之外还有一些其他可以优化的地方存在这些点在后续的OIDC的文章中再做介绍吧感兴趣的可以看一看http://openid.net/connect/中关于OAuth2的另外一些相关扩展标准草案这些标准也是OIDC所需要的一些可选支持。另外在一些场景下使用JWT来使得OAuth2的提供自描述的Token还是一件很方便的事情的。
以上内容均是个人的一些理解如果错误之处欢迎指正
6. 参考
JSON协议RFC7159 - The JavaScript Object Notation (JSON) Data Interchange Format
OAuth2 扩展协议
RFC7009 - OAuth 2.0 Token Revocation
RFC7662 - OAuth 2.0 Token Introspection
OAuth相关扩展草案https://datatracker.ietf.org/wg/oauth/charter/
JWT相关协议族
RFC7515 - JSON Web Signature (JWS)
RFC7516 - JSON Web Encryption (JWE)
RFC7517 - JSON Web Key (JWK)
RFC7518 - JSON Web Algorithms (JWA)
RFC7519 - JSON Web Token (JWT)
JWT官方站点https://jwt.io
Claimshttps://en.wikipedia.org/wiki/Claims-based_identity
JWT注册的的一组Claims : https://www.iana.org/assignments/jwt/jwt.xhtml
相关文章:
Thinktecture IdentityServer.NET开源OpenID和OAuth解决方案教你实践ASP.NET Core Authorization免看文档教程双重OAuth 2.0架构[认证授权] 1.OAuth2授权
原文地址http://www.cnblogs.com/linianhui/p/oauth2-extensions-protocol-and-json-web-token.html.NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
