认证

HTTP Basic Auth

HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password，简言之，Basic Auth是配合RESTful API 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用HTTP Basic Auth

OAuth

OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容

下图展示认证流程：

20180128220125644

这种基于OAuth的认证机制适用于个人消费者类的互联网产品，如社交类APP等应用，但是不太适合拥有自有认证权限管理的企业应用；

Cookie-session 认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效；
但是这种基于cookie-session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来。

基于session认证暴露的问题：

session：

每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

扩展性：

用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF：

因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击

Token Auth

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程：

1，用户使用用户名密码来请求服务器

2，服务器进行用户信息的校验

3，服务器通过验证发送用户token

4，客户端存储token，并在每次请求附送token

5，服务器验证token，返回数据

token必须每次请求时传递给服务器，应该保存在请求头中；除此外，服务器要支持CORS（跨站资源共享），我们在服务器配置 Access-Control-Allow-Origin即可

20180128221202239

优点

支持跨域访问

无状态

适用CDN，移动应用

不需防范CSRF

基于标准化JWT（Json Web Token）

基于JWT的token认证机制简述

WT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准（RFC 7519），定义了一种简洁的，自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在，这些信息是可信的，JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

简洁(Compact)
可以通过URL，POST参数或者在HTTP header发送，因为数据量小，传输速度也很快
自包含(Self-contained)
负载中包含了所有用户所需要的信息，避免了多次查询数据库

主要应用场景

  • 身份认证

此场景下，用户完成登录，接下来的请求中包含JWT，验证用户身份以及对路由、服务和资源的访问权限进行验证。开销较小，可在不同域名的系统中传递，目前在单点登录（SSO）中广泛应用

  • 信息交换

通信双方使用JWT对数据编码非常安全，由于信息经过签名，可确保发送者发送的消息没有经过伪造

认证过程

微信截图_20220408092520

请求认证

微信截图_20220408092512

JWT结构

  • Hearer 头部

头部承载两部分信息 -> 声明类型 jwt；声明加密算法，通常使用HMAC SHA256

例：{ "typ": "JWT", "alg": "HS256" } ，而后使用base64加密，构成第一部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

  • Payload 载荷

存放有效信息，包含 -> 注册声明，公共声明，私有声明

注册声明：（JWT预先定义，不强制使用但推荐）

iss（签发者）、sub（面向用户）、aud（接收方）、exp（过期时间）、nbf（不可用时段）、iat（签发时间）、jti（唯一身份标识，主要用做一次性token，避免重放攻击）

公共声明：

添加任何信息，如用户信息，业务信息等，不建议添加敏感信息，该部分客户端可解密

私有声明：

提供者和消费者所共同定义的声明

例： { "sub": "1234567890", "name": "John Doe", "admin": true } ，将其base64加密，构成第二部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

  • signature 签名

签证信息，构成 -> header（加密后），payload（加密后），secret

加密后的头部和载荷，经过声明的加密方式（HS256）进行加盐（secret）加密，构成第三部分

安全问题

1，确保过程安全性

建议采用HTTPS，用SSL加密传输，确保通道安全

2，防范XSS Attacks

  • XSS代码过滤

    js下的js-xss，java下的xss hTMLFilter，php下的TWIG

  • HTTP-Only cookies

3，防范Replay Attacks

  • 时间戳+共享密钥
  • 时间戳+共享密钥+黑名单

4，防范MITM（Man-In-The-Middle） Attacks

建议采用HTTPS，用SSL加密传输，确保通道安全

posted @ 2022-06-08 16:19  lifelikeplay  阅读(147)  评论(0)  编辑  收藏  举报