Outh2的官方b话很多, 我这里只说白话和实现步骤
统一几个名词:- 第三方: 社交登录的服务器, 也就是第三方网站
- 本系统: 自己的前端页面和服务器
- 本系统首页: 用户登录后会访问首页, 也就是说首页是一个在用户登录后才有权限看到的界面
- 令牌code: 用来换取用户token, 只能使用一次
- accessToken: 你真正可以通行的, 使用他可以获取权限资源的东西
我分为几个角度去看, 可以着重找自己关注的角度去看, 比如你是后端开发,就直接看后端角度
用户角度 – 前端角度 1, 访问本系统
本系统前端肯定有一个到第三方的一个链接按钮, 比如一个[QQ登录]的按钮
2, 用户点击按钮, 跳转到第三方的登录页面用户输入第三方的账号密码, 进行第三方系统的登录
3, 第三方系统登录完成后, 第三方回调本系统, 本系统自动完成登陆, 打开首页此步骤, 用户无感知, 只知道这步骤就进入到了本系统的首页了
本系统角度 - 后端角度
后端肯定源自于前端, 所以大体步骤肯定和前端一致, 最重要的是, 将用户角度的第三步, 给拆分出来
从上边可以看出来, 得理清楚这个事, 登录的决定权是在第三方, 本系统只做静默登录, 因此关键是, 建立本系统和第三方的关系
用户点击 [第三方登录按钮] 后, 跳转到第三方的登录链接, 本系统需要携带上, client_id,redirect_url(授权后获取令牌的url, 非本系统首页)…等等需要的参数
2,第三方携带令牌回调本系统第三方回调我们的url, 这个url可以称为授权回调页, 第三方的url会携带一个令牌code, 需要注意的是这个并非是真正的用户信息token,
注意: 这个令牌code只能使用一次, 请求一次, 就要更新一次, 而且后续虽然令牌code不一样, 但是token一致的
3, 本系统到第三方, 换去访问token第三方调用了我们的授权回调页后, 我们在这个方法中, 由后端发起一个请求给第三方, 访问第三方的获取用户信息的url, 请求时,按照第三方规定, 携带一些参数, 比如: redirect_url(本系统首页), client_id, client_secret等参数, 当然第二步获取的令牌code也必须传
4, 使用token获取第三方公开信息调用第三方的token获取url, 获取到第三方的accessToken, 这个accessToken才是真正的用户信息token使用这个accessToken可以获取到第三方给你开放的一些信息, 然后本系统根据这些信息做处理,比如根据accessToken获取到用户信息, 然后在本系统进行自己的登录或者注册逻辑
简洁说1, 本系统到第三方的登录页面
2,第三方携带令牌回调本系统, 后端代码访问第三方, 换去访问token
3, 使用token获取用户, 或者获取第三方公开信息, 进行自己的登录
感受
了解这个Outh2的时候, 我就奇怪, 为什么用户在第三方输入账号密码后, 直接返回给本系统一个token, 而是先返回一个code, 用code去换token,
后续个人感觉,
一就是为了安全, code是一次性的,总不能一直换token吧, 当然这么说也很牵强, 我78加盐值加密token, 一次不行, 两次, 两次不行,三次, 不也很安全嘛, 当时问一个公司大哥, 也是这么说, 为了安全, 你还不说为了德玛西亚?
二就是, 人家这个Outh2是一个概念, 像是从道德制高点给你约定的这么个模式, 就是综合了很多因素给你这么设计的, 个人觉得, 你可以做为参考, 但是别用人家给你约定的写名词, 去追崇;你去学习这个东西, 你可以用术语去理解去感受, 但是沟通的时候, 用白话不就行了吗?非说一个客户端代理,你直接说一个浏览器, 是片面了, 但是是不是更好的沟通了, 而且你聊天都是针对性场景的, 你目前就是用浏览器, 也没有安卓, ios前端呀, 何必呢
反正说, 人家是一个规范, 考虑的因素很多, 比如说, 人家可能觉得你的认证服务器, 可能是别的语言, 而且你的存储token的中间件, 可能也不只是redis;
总结讲就是, 第三方的登录服务器可能是多种的, 并非和你本系统的语言, 中间件什么的都一致, 甚至人家的资源服务器和认证服务器都不是一个应用, 因此才会麻烦一点, 先得到令牌, 再去换token; 类似于一种解耦的感觉吧, 你认证就来光认证, 我给你一个标识(令牌code), 你认证成功了, 你再来要资源, 给我我需要的code, 我再给你需要的token
