协议流

协议流

如图1所示的抽象流描述的四种角色之间的互动还包括了一下步骤:

(A)client(就是application)向resource owner请求授权。可以直接向resource owner请求,但更好的是通过authorization server作为中间物间接获得。(比如新浪微博的是否允许授权的页面)。

(B)client获得了resource owner的授权认可(authorization grant),此授权认可是四种标准授权认可类型中的一种,也可以是其中一种的扩展类型。获得的授权认可的类型由client请求授权所使用的函数和authorization server支持的类型决定。(比如采用特定的请求授权的url,但是传入不同的参数,或者使用的method不同,当然一切都至少服务器要支持)。

(C)client提供授权认可,以请求一个access token,该token是可以被authorization server验证的。

(D)authorization server验证client,并且核实授权认可,如果是有效,就发放access token。注意这里是两个验证,1验证client是不是被承认的,2验证resource owner是不是真的授权了。

(E) client提供access token给resource server验证,判断此client是否可以获取受保护的资源。

(F) resource server核实access token,如果有效则响应请求。

土豪请注意: 如果您觉得此文有帮助,可以给支付宝账户zuiyanwangyue@126.com转账进行打赏(可扫描右侧二维码),您的捐助将被用于完善此网站的功能和内容。
加入我们团队: 如果你是技术控并且愿意分享自己掌握的知识,欢迎加入我们团队,请联系QQ:421712311 如本文未能解决您面临的问题,也欢迎随时和我联系以便进一步探讨。

评论列表[0]