赞
踩
OAuth 定义了四个角色:
能够授予对受保护资源的访问权限的实体。当资源所有者是一个人时,它被称为最终用户
托管受保护资源的服务器,能够使用访问令牌接受和响应受保护资源请求
代表资源所有者并经其授权发出受保护资源请求的应用程序。“客户”一词确实 不暗示任何特定的实现特征(例如, 应用程序是否在服务器、桌面或其他 设备上执行)。
服务器在成功 验证资源所有者并获得授权后向客户端颁发访问令牌。授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器 可以是与资源服务器相同的服务器,也可以是单独的实体。 单个授权服务器可以发布多个资源服务器接受的访问令牌。
这种方式是最常用的流程,安全性也最高,它适用于那些有后端的 Web 应用。授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏
1:用户访问页面
2:访问的页面将请求重定向到认证服务器
3:认证服务器向用户展示授权页面,等待用户授权
4:用户授权,认证服务器生成一个code和带上client_id发送给应用服务器
然后,应用服务器拿到code,并用client_id去后台查询对应的client_secret
5:将code、client_id、client_secret传给认证服务器换取access_token和
refresh_token
6:将access_token和refresh_token传给应用服务器
7:验证token,访问真正的资源页面
如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)
1:用户访问用页面时,输入第三方认证所需要的信息(QQ/微信账号密码)
2:应用页面那种这个信息去认证服务器授权
3:认证服务器授权通过,拿到token,访问真正的资源页面
有些 Web 应用是纯前端应用,没有后端。这时就不能用上面的方式了,必须将令牌储存在前端。RFC 6749 就规定了第二种方式,允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)“隐藏式”(implicit)
1:用户访问页面时,重定向到认证服务器。
2:认证服务器给用户一个认证页面,等待用户授权。
3:用户授权,认证服务器想应用页面返回Token
4:验证Token,访问真正的资源页面
适用于没有前端的命令行应用,即在命令行下请求令牌
1:用户访问应用客户端
2:通过客户端定义的验证方法,拿到token,无需授权
3:访问资源服务器A
4:拿到一次token就可以畅通无阻的访问其他的资源页面
如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。