OAuth2.0这个名词你是否在项目中时常听到呢?是否以为好像懂,又好像不太懂呢?前端
最近一直想写篇关于OAuth2.0的东西,记录下个人学习与感悟,然各类理由的拖延,直到今日才静下心来写下这篇博客。固然,这里仅表明我的理解,若有纰漏之处,望园内大佬们不吝赐教~安全
好了,话很少说,干货顶上。服务器
在接触OAuth2.0时是否常听到认证和受权这两个名词呢?学习
刚接触时,一直觉得这两个词是一个意思,只是你们说法的不一样而已。然,在看完官方开发文档后才知道,这根本就是两个东西,不能混为一谈。下面详细说说:加密
如今看看,是否是挺简单的概念,顿时清晰起来?spa
访问令牌,其实就是能够访问受保护资源的一个凭证。通常而言,这是串加密过的字符串,颁发给客户端,用于替换用户名和密码,避免每次请求都携带用户名密码,增长安全风险。代理
上面这张图即是OAuth 2.0抽象的协议流程,描述了其定义的四个角色之间的交互关系。我将这个流程分为了前期准备和获取资源两个部分,详细以下:blog
前期准备(这是一次性操做,可经过界面申请,与资源拥有者的用户代理沟通等):token
获取资源(Restful请求,每次访问资源都得通过该操做):ip
受权成功其实就是资源拥有者颁发的能够访问受保护资源的凭证。固然客户端直接拿着凭证是没法访问资源的,还需拿着这个凭证去受权服务器拿访问令牌,凭着令牌即可直接访问受保护资源。
OAuth 2.0官方给出的规范,受权的具体方式共有四种(可自定义):资源拥有者密码凭证,客户端凭证,受权码和隐式受权,;固然自定义机制也是支持的。
资源拥有者密码凭证的受权方式仅适用于资源拥有者和客户端高度信任的场景。
客户端携带自身凭证(clientId: secret)直接去受权服务器获取访问令牌
一次性操做(受权码只须要获取一次便可):
获取资源:
优点:对客户端进行认证;访问令牌没有直接返回至客户端,因此没有经历第三方(用户代理),减小暴露令牌的可能。
隐士受权是个简化的受权流程,适用于前端页面由脚本语言(如Javascript)编写的场景,对于React,Angular等编写的前端,建议使用受权码的受权方式。
注意:通常隐式受权,能够利用重定向URI进行客户端认证。
做者:吴家二少
博客地址:https://www.cnblogs.com/cloudman-open/
本文欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面明显位置给出原文链接