OAuth

1. 起因 在配置Directus使用钉钉扫码登录时候，发现钉钉的免密登录（OAuth 2）和RFC规范不一致。 需要做协议转换后才能和Directus正常通信。 需求比较小众，没有现成的软件，只好自己动手了。 2. 主要功能 能作为API通信的中间人， 转发客户端和API服务器之间的通信， 记录LOG，方便分析协议； 作为中间人，能修改请求的内容， 修改响应的内容；可以做协议适配，转换。 APIPROXY is a RESTFUL API proxy, monitor and adaptor. Forward RESTFUL API to another host. It’s man in the middle who can monitor and modify the header and body of the API Request & Response. Good for protocol study and adaptation. Features API proxy: forward any incoming API to remote sever and return the response back to client. API monitor: you can get detailed log of the API req and res in the log file. API adpator: modify the request and response on the fly while forwarding, including parameters, body, http headers etc. API mock server: you can add your own API for testing purpose easily. 3. 目前状态 初步实现了对钉钉OAuth2协议的RFC6749兼容封装。 目前Directus已经可以通过它的翻译支持钉钉免密登录。 ...

1. 项目简介 这个小项目预期结果是让 Directus 支持使用钉钉账号来登录。 在了解OAuth2协议后(参见上一篇blog，参考资料1），已经有足够知识储备来实施。 Directus 原生支持使用GitHub登录， 所以，解决思路是先从GitHub入手。按下面步骤进行： 配置Directus使用GitHub账号登录，熟悉Directus对OAuth的标准支持功能 配置Directus使用钉钉账号登录，由于钉钉的协议实现和RFC6749/GitHub有不同，这里有可能需要见招拆招 上线Directus到服务器环境，在钉钉的PC版和手机版验证 2. 环境配置 在本地用ngrok暴漏出一个服务，来接受OAuth服务器的redirect。 ngrok http 8055 得到 https://445a-240e-47c-30b0-3b10-600e-ea25-cde5-2334.ngrok.io/ 作为外网域名来访问本机8055端口的directus。 3. Directus 使用 GitHub账号登录 按参考资料2中配置参数。以下配置中，对每一个新的GitHub授权用户，Directus在登录过程中会使用用户email自动创建一个Directus用户，并且将其角色赋值为AUTH_GITHUB_DEFAULT_ROLE_ID。 A A A A A A A A A A # # U U U U U U U U U U T T T T T T T T T T A A H H H H H H H H H H U U _ _ _ _ _ _ _ _ _ _ T T P G G G G G G G G G H H R I I I I I I I I I _ _ O T T T T T T T T T G G V H H H H H H H H H I I I U U U U U U U U U T T D B B B B B B B B B H H E _ _ _ _ _ _ _ _ _ U U R D C C A A P A D I B B S R L L U C R L E C _ _ = I I I T C O L F O E I " V E E H E F O A N M D g E N N O S I W U = A E i R T T R S L _ L " I N t = _ _ I _ E P T g L T h " I S Z U _ U _ i _ I u o D E E R U B R t K F b a = C _ L R L O h E I " u " R U = L I L u Y E t 7 E R " = C E b = R h e T L h " _ _ " " _ 2 . = = t h R I e K " . " " t t E D m E . d h p t G = a Y . 5 t s p I " i = a . t : s S 0 l " e . p / : T f " e " . s / / R 5 m . : g / A f a . i a T 1 i . t p I b l . g h i O 5 " d i u . N a 9 t b g = - " h . i " 1 u c t t 0 b o h r 6 . m u u f c b e - l . " 4 m c e g o c l i m 7 o n - g u a i o s 8 n a e b / u r 8 o t " - a h 6 u / f t a 1 h c 1 / c 4 a e 8 u s 2 t s a h _ 0 o t 6 r o 0 i k f z e " e n " " 重启Directus让配置生效后，可以看到登录界面的GitHub选项。 ...

1. 原理 假设有一个APP，要我使用GitHub授权登录。 在这个登录场景中： 我作为数据的所有者告诉系统（GitHub），同意授权第三方应用（App）进入系统，获取某些数据（我的ID，头像等）。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用（APP）访问数据使用。 token是短期有效的，我可以随时通过GitHub把这个Token注销，从而使得APP不再能访问我的ID/头像等信息。 这里面有四个角色：用户，应用，系统，资源。 用户是资源所有者，应用是资源的使用者，系统是资源管理者。 现实生活中， 应用和系统各自有一个实例， 用户有多个实例。 应用和系统之间通过OAuth2协议通信。 用户在通信过程中参与（授权）。 把上面时序图对应到一个生活中的场景，业主授权快递公司出入小区送快递： Client Req Auth： 顺丰快递员打电话给业主，有你的快递，得送进去，给办个出入证吧 Resource Owner Grant Auth： 业主联系小区物业， 我是业主，这是我的证明，我允许顺丰最近两天可以进小区物业给我送快递 小区物业告诉业主，OK，你让顺丰联系我拿临时出入证，就说3号楼201房间，授权码：核酸检测利国利民 Client Sends Auth Grant 快递公司联系小区物业说，我是顺丰，这是我的证明，需要给3号楼201房间送快递，业主的授权码是核酸检测利国利民 Auth Server Sends Access Token 小区物业说好，授权码没问题，这个是临时出入证，两天有效。 Clients Sends Access Token 快递员用临时出入证开小区大门 Protected Resoure sends resource 快递员进入小区 注意： 第二步，业主联系物业时候， 要证明自己的确是业主（用小区app登录） 第三步，顺丰联系物业时候，需要证明自己的确是顺丰（报小区物业预先给顺丰分配的client_secret让物业核对). 物业还要检查3号楼201业主的确允许了（通过查授权码）。 如果快递员直接到小区门卫那里说 “核酸检测利国利民”，是没有作用的。“核酸检测利国利民”承载的信息是3号楼201业主允许顺丰在2天内进小区。 快递员给门卫报这个授权码没用，门卫只认出入证。再说，门卫也不知道快递员是不是顺丰的啊。这个授权码只有在快递公司把它换成临时出入证后才可以进小区。 换临时出入证需要验证顺丰的身份。“核酸检测利国利民”承载的信息是可以公开的，其它人听到了也不会有安全风险，因为其他人没有顺丰在物业处注册得到的client_secret, 没办法用授权码换临时出入证。 临时出入证需要妥善保管，任何人拿着都能进小区了。 OAuth2的过程是当有快递时候，业主授权小区物业给快递公司分配临时出入证，在一定的时间内可以出入小区。在同一时间，会存在很多个不同业主授权的有效临时出入证，但一个业主对一家快递公司，在同一时间只有一个有效临时出入证。 角色间的类比关系如下。 中文术语 时序图中的概念 GitHub授权登录APP场景 业主授权顺丰进小区场景 用户 Resource Owner GitHub用户 业主 应用 Client GitHub OAuth APP 顺丰 系统 Authorization Server GitHub 小区物业 资源 Protected Resource GitHub用户名称，头像 小区内部道路 授权 Authorization Grant code 核酸检测利国利民 令牌 Access Token token 临时出入证 下图出自RFC6750， 实际实现时候，Client是APP， Auth Server/Resource Server在同一个域名后面（GitHub，钉钉，Facebook…)， Resource Owner也是在这个域名下完成授权（Auth Grant）。 ...