本文主要介绍了 oauth2.0 单点登录 中的最完整的授权码模式
期望
一个授权平台处于登录状态的时候,访问其他受信任的平台都可以跳过登录直接访问,其实是使用授权平台的身份信息进行的登录,即我们生活中常见的第三方软件微信登录这种。
Oauth2.0
概念:OAuth 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。
角色:
- 服务提供方(微信),用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表,用户信息。
- 用户(我们自己),存放在服务提供方的受保护的资源的拥有者。
- 客户端(对接单点的系统),要访问服务提供方资源的第三方应用,并使用访问到的信息进行第三方应用的登录。
通俗的讲就是我们告诉微信,同意第三方应用进入微信获取我们的用户信息,微信为第三方应用生成一个短期的 token 用来代替密码,第三方应用可以使用 token 访问接口获取用户信息。
服务提供方(微信)需要具备的能力
其实就是三个接口
接口 | 使用者 | 返回 | 作用 |
---|---|---|---|
重定向跳转地址 | 后端在检测到登录 cookie 过期时返回前端该 url,前端在浏览器进行跳转 | 服务端会重定向到提供的redirect_uri 并在地址上拼接code和state | 用于向前端返回 code |
code 换 token 的接口 | 前端在上一步拿到 code 后,作为参数向后端发起 ajax 请求,后端调用该接口换取 token | 用来请求用户信息的 token | code 换 token |
token 换用户信息 | 后端在拿到 token 后作为参数调用接口获取用户信息 | 三方业务需要的用户信息 | token 换 userInfo |
单点登录流程
上述流程是一个完整的第三方应用使用服务提供方进行单点登录所经历的完整流程。
流程图可以在这里画
@startuml
actor 用户 as role1
participant 前端 as role2
participant 后端 as role3
participant 服务提供方 as role4
database redis as role5
role1 -> role2 : 用户操作
role2 -> role3 : 发起 ajax 请求
role3 -> role2 : cookie 过期并回传 url
role2 -> role4 : 前端根据 url 跳转至 服务提供方
role4 -> role1 : 服务提供方 没登录则进行登录
role1 -> role4 : 用户登录授权
role4 -> role2 : 登录成功后服务提供方根据 redirect_uri 进行回跳并携带 code 码和参数中的 state 值
role2 -> role3 : 前端通过 ajax 发送 code
role3 -> role4 : 后端使用 code 访问服务提供方获取 access_token
role3 -> role4 : 后端使用 access_token 访问服务提供方获取 user_info
role3 -> role5 : 后端生成 cookie 值和 userInfo 作为键值对存入 redis 并设置过期时间
role3 -> role2 : 后端响应前端并向浏览器写入相同过期时间的 cookie
role2 -> role2 : 前端跳转之前获取到的 state 地址,如没有,可自己定义
@enduml