微信公众号:BoomDev
如有问题或建议请留言
最近更新:2018-10-16
终于理解了登录、授权是怎么一回事
登录和授权的区别
- 登录:身份认证,确认 你是你。登录包含授权
- 授权:由身份或持有的令牌享有的某些权限(例如用户信息)
在实际应用中,多数场景下的「登录」和「授权」界限是模糊的
HTTP 中确认授权(登录)的两种方式
通过Cookie
工作机制
- 服务器需要客户端保存的内容,放在
Set-Cookie
header 里返回,客服端会自动保存 - 客服端保存的 Cookies,会在之后的所有请求中都携带进
Cookie
header 里返回给服务器 - 客户端保存的 Cookie 是按服务器域名来分类的,例如 shop.com 返回的 Cookie 保存下来以后,在之后向 games.com 的请求中并不会携带。
- 客户端保存的 Cookie 在超时后会删除、没有设置超时时间的 Cookie (Session Cookie)在浏览器关闭后就会自动删除;另外,服务器也可以主动删除还未过期的客服端 Cookies
Cookie 的作用
- 会话管理:登录状态、购物车
- 个性化:用户偏好、主题
- Tracking:分析用户行为
通过 Authorization Header
两种主流方式:Basic 和 Bearer
Basic :
- 格式:Authorization:Basic
Bearer :
- 格式:Authorization:Bearer
- brarer token 的获取方式:通过 OAuth2 的授权流程
- OAuth2 的流程:『掘金网站用 GitHub 登录』
- 第三方网站(掘金)向授权方网站(GitHub)申请第三方授权合作,拿到 client id 和 client secret
- 用户在使用第三方网站(掘金)时,点击「通过 XX(如 GitHub)授权」按钮,第三方网站(掘金)将页面跳转到授权方网站(GitHub),并传入 client id 作为自己的身份标识
- 授权方网站(GitHub)根据 client id ,将第三方网站的信息和第三方网站需要的用户权限展示给用户,并询问用户是否同意授权
- 用户点击「同意授权」按钮后,授权方网站(GitHub)将页面跳转回第三方网站(掘金),并传入 Authorization code 作为用户认可的凭证。
- 第三方网站(掘金)将 Authorization code 发送给自己的服务器
- 服务器将 Authorization code 和自己的 client secret 一并发送给授权方(GitHub)的服务器,授权方服务器在验证通过后,返回 access token。OAuth 流程结束。
- 结束之后,第三方网站的服务器(或者有时客服端也会)就可以使用 access token 作为用户授权的令牌,向授权方网站发送请求来获取用户信息或操作用户账户。这已经是 OAuth 流程之外的事了。
- 在自家 APP 中使用 Bearer token
有的 App 会在 Api 的设计中,将登陆和授权设计成类似 OAuth2 的过程,但简化掉 Authorization code 的概念。即登陆接口请求成功时,会返回 access token,然后客服端在之后的请求中,就可以使用这个 access token 来当作 bearer token 进行用户操作了。
- Refresh token
access token 有失效时间,在它失效后,调用 refresh token 接口,传入 refresh_token 来获取新的 access token
TCP / IP 协议镞
为什么要分层?
网络太复杂,不稳定
- Application Layer 应用层:HTTP、FTP、DNS
- Transport Layer 传输层:TCP、UDP
- Internet Layer 网络层:IP
- Link Layer 数据链路层:以太网、Wi-Fi
TCP 连接
- 客户端:「我要向你发送消息」
- 服务器:「好的。我要向你发送消息」
- 客户端:「好的」
TCP 连接关闭
- 客户端:「我不再给你发送消息」
- 服务端:「好的」
- 服务端:「我不再给你发送消息」
- 客户端:「好的」
HTTPS
HTTPS:HTTP over SSL ,既工作在 SSL(或 TLS)上的 HTTP。加密通信的 HTTP
工作原理
在客服端和服务器之间协商出一套对称密钥,每次发送信息之前将内容加密,收到之后解密,达到内容的加密传输
为什么不直接用非对称加密
非对称加密由于使用了复杂的数学原理,计算相当复杂,如果完全使用非对称加密来加密通信内容,会严重影响网络通信的性能
HTTPS 连接建立的过程
- Client Hello
- Server Hello
- 服务器证书 建立信任
- Pre-master Secret
- 客户端通知:将使用加密通信
- 客户端发送:Finished
- 服务器通知:将使用加密通信
- 服务器发送:Finished
在 Android 中使用
正常情况
直接使用
需要自己写证书验证过程的场景
- 用的是自签名证书(例如只用于内网的 https)
- 证书信息不全,缺乏中间证书机构(可能性不大)
- 手机操作系统较旧,没有安装最新加入的根证书
我是一名有备而来的 Android 工程师
微信公众号:BoomDev
欢迎关注我、一起学习、一起进步!