这篇文章是我在公司内部分享的 paper（去掉了敏感信息之后），在这里贴一下~
- 什么是认证和授权
- 有哪些方式
- 我们是怎么设计的
认证和授权
| 认证 authentication | 授权 authorization |
|---|---|
| ~~X~~ | ~~√~~ |
| X | X |
| √ | X |
| √ | √ |
- 公开的数据/可以匿名访问的
- 验证有效的 user
- 需要 ACL 系统验证
有哪些方式
- Cookie 与 Session
- Basic Auth
- JWT
- OAuth2
Cookie 与 Session
- Cookie：键值对；Set-Cookie
- Session：浏览器存储 cookie，包含 session-id；服务端验证 session-id 有效性，并获取 user 信息
- 优点：简单
- 缺点
- 对非浏览器端不友好
- CSRF：Cross Site Request Forgery，跨站请求伪造
Basic Auth
- Header:
Authorization: "Basic " + base64(username:password) - 优点：简单
- 缺点
- 明文传输用户名和密码
- 无法提供更多有效信息，只有用户名
JWT
- JWT：JSON Web Token
- 由三段构成：header、payload、signature，三段都进行 base64 编码，由”.”连接起来
- header：类型与摘要算法（{'typ': 'JWT','alg': 'HS256'}），指示其余部分如何解析与生成
- payload：Issuer/Audience/Expiration Time/Issued At，任何需要的业务信息
- signature：使用第一段的签名算法对前两段的数据进行签名
- 保证有效性：第三段信息对前两段信息进行摘要，保证前两段信息没有被篡改
- 摘要算法可以是对称的，也可以是非对称的
- 优点
- 不需要中心服务器，可以独立的验证有效性（非对称）
- 不需要服务器存储
- 缺点
- 无法主动失效已经签发的 jwt token
- 过期需要重新登录
OAuth2
- 两种：access_token 和 refresh_token（optional）
- 签发与验证、刷新
- 与 OAuth1 对比
- 新增了 refresh_token（optional）
- access_token 变短
- 使用更简单
- 优点
- 使 access_token 有效期变短，access_token 的泄露造成的危害性有时间限制
- 可刷新，token 过期的时候，不需要重新登录
- 缺点
- refresh_token 提高了客户端操作的复杂性
- 客户端刷新操作复杂
- access_token 是否在服务端存储 memory/redis/mysql？
时序图
第三方授权时序图
# 我们是怎么设计的
安全性
- HTTPS
- 弱口令/暴力破解
- 二次验证 Two-factor Authentication