关于OAuth2的密码式令牌
想写个不需要登录,无需维护Session或Cookie等状态的纯RESTful API,但是又需要有身份认证和权限鉴别功能。比如我有一套爬来的金融数据API,想让指定的用户使用,其他人访问就报401。最近用FastAPI,里面提供了OAuth2以及scopes的密码式令牌鉴权机制,十分方便,但是部分场景也容易造成信息泄露。
OAuth2密码式令牌应用场景
众所周知OAuth2有四种应用场景各不相同的鉴权方式,其中,密码式可以说是在互联网环境中最不安全的一种了,因为你需要将你在诸如微信的用户名密码一类的信息告诉一个第三方应用,而后第三方应用拿着你的用户名密码去向微信申请数据。如果是在互联网上使用这种验证方式,你必须极度信任这个第三方应用,不然就是社会性自杀。
那么,这样一个危险的鉴权方式有什么实际作用呢?那当然是可控网络环境中,对各业务系统API进行集中访问控制了——毕竟现在微服务这么火,就算是内网应用也应该试试开放几个API吐出点数据——这样PPT上就可以写打破数据孤岛了✌️。
比如,我有很多业务系统,以系统A为例。a.com
开放了两个API:
- 查看当前用户的信息
http://a.com/me
; - 查看当前用户拥有的数据条目
http://a.com/me/items
。
这时候有人想调用这俩API,而A系统管理员只希望指定的人用,此外,还有XYZ的各种业务系统,都有这种需求,如何在不使用session、cookie这种有状态身份认证的情况下(调用API还要先认证个session太麻烦了)直接在请求中附带一个通行证就调用API,还要保证安全和权限分级呢?
OAuth2密码式令牌应用环境
密码式令牌提供了一个简单的解决方案:
- 在A系统上开一个发通行证
access_token
的窗口:http://a.com/token
。
- 系统中有个加解密的秘钥
SECRET_KEY
; - 通行证窗口是一个可以被A系统全信任的窗口,不私存用户名密码,就是个工具窗口。
- 通行证窗口接受用户认证信息,返回一个
jwt
库使用秘钥SECRET_KEY
加密的通行证。 - 通行证窗口接受方式规定为HTTP POST方式。接受如下的表单,其中
scope
为表示权限的字符串,以空格为分隔符:1
2
3
4grant_type: password
scope: me items
username: johndoe
password: secret - 通行证窗口拿到用户名密码后确认身份,并取出库中的权限列表与请求中的权限列表进行核对,如果请求的权限多于在册的权限,则http-401,反之则放行。
- 通行证窗口返回的通行证为json格式,通行证的内容包含认证用户ID、权限列表、通行证有效期,例如
1
2
3{"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqb2huZG9lIiwic2NvcGVzIjpbIm1lIiwiaXRlbXMiXSwiZXhwIjoxNTk0MTI2MjkxfQ.AimqzTZg1t7XHstWi-048prkRAPv6-m-IM9OfGYio8A","token_type":"bearer"}
// 其中access_token解密后的明文形为
{'sub': 'johndoe', 'scopes': ['me', 'items'], 'exp': 1593831859}
- A系统提供了很多API:
- 查看当前用户的信息
http://a.com/me
; - 查看当前用户拥有的数据条目
http://a.com/me/items
。 - …
- 系统中有个加解密的秘钥
SECRET_KEY
,与发通行证的窗口用的一样; - 这些API都有身份验证机制,具有独立的权限列表要求,需要提供OAuth2通行证令牌,
jwt
库使用秘钥SECRET_KEY
对令牌解密,以验明正身。
- A系统管理员维护着一个用户及权限表,包括用户名
username
(如johndoe
)、密码hashed_password
、权限列表scope
(如['b/me', 'b/items']
)。
OAuth2密码式令牌调用流程
此时,第三方系统B想要调用业务系统A的API,比如有人想要调用http://a.com/me
,那么A系统如何认证用户和权限呢?
- B需要获取A库表中的某个用户名密码:
- 这个动作可以是A管理员给B的,比如我A系统就开一个API专用账户,你B拿着这个账号就随便临幸我A吧。(这种通常权限开的尺度比较大)
- 也可以是A的一个用户给B的,用户aaa表示你B系统可以去A系统拿我的某些数据。
- B拿着用户名密码去A的通行证窗口申请通行证:
- 通行证窗口就是负责接收用户名密码,确认在A的库表中后,发通行证。
- 查无此人直接http-401。
- B拿到通行证,在每一次对A系统的API请求Header中附带这个通行证:
- 例如,在访问
a.com/me
时加上Authorization
头部字段,其值形为Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqb2huZG9lIiwic2NvcGVzIjpbIm1lIiwiaXRlbXMiXSwiZXhwIjoxNTk0MTI2MjkxfQ.AimqzTZg1t7XHstWi-048prkRAPv6-m-IM9OfGYio8A
。
- A的API会拿到
Authorization
头部字段,取出其中的通行证,解密,获取其中的用户名、权限、有效期:
- 若令牌可解密,且在有效期内,比对API所需的权限与请求通行证提供的权限,若提供满足所需,则API响应并返回,反之则http-401。
OAuth2密码式令牌代码示例
1 | from datetime import datetime, timedelta |
总结
在网络环境较为透明可控的场景下,使用OAuth2的密码方式对开放的API进行身份及权限验证,是一种安全、可控、简便的管理方法。除上文描述的方法外,还可以将各应用系统的权限收口统一管理,维护一个用户权限库表,将通行证的发放维护在一个入口中,再于各应用系统中约定同一个加解密秘钥,可进一步方便管理。当然,这些方法的前提必须是网络环境较为透明可控。