JWT、OAUTH2、Session ID 是什么？

什么是 JWT，OAUTH2，以及 Session ID

JWT

JWT（JSON Web Token）是一种用于在网络应用之间安全传递信息的开放标准。它通过将信息编码成 JSON格式并使用数字签名或加密来确保数据的完整性和安全性。JWT 常常用于身份验证和声明传递，特别是在分布式系统中。

一个 JWT 通常由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）：

头部（Header）：头部通常由两部分组成，它们使用 Base 64 编码后合并在一起，并用点号分隔。头部包含有关令牌的元信息，如令牌的类型（通常是 “JWT” ）和使用的签名算法。例如：
```
{
  "alg": "HS256",
  "typ": "JWT"
}
```
这个头部指示使用了 HMAC SHA-256 算法进行签名，并且令牌的类型是 JWT。
载荷（Payload）：载荷也是一个 JSON 对象，它包含要传递的信息，以及一些声明（claims）。声明可以分为三类：注册声明、公共声明和私有声明。注册声明是预定义的声明，例如发行者（”iss”）、主题（”sub”）和到期时间（”exp”）。公共声明是用于自定义的声明，但建议避免与已有的声明名冲突。私有声明是由用户定义的自定义声明。

载荷部分也会被 Base 64 编码，但不会被加密，因此可以被解码查看。例如：
```
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```
这里的载荷包含了用户 ID、用户名和令牌的发行时间。
签名（Signature）：为了验证消息的完整性和来源，签名是 JWT 的重要部分。签名是由编码后的头部和载荷，以及一个密钥组合生成的哈希值。签名的过程通常使用所选的算法，如 HMAC SHA-256，以确保只有持有正确密钥的人才能够验证和解码令牌。

最终的 JWT 会由三部分以点号分隔组成：
```
base64urlEncode(Header) + "." + base64urlEncode(Payload) + "." + Signature
```
完整的 JWT 看起来像这样：
```
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eyJzdWIiOiAiMTIzNDU2Nzg5MCIsICJuYW1lIjogIkpvaG4gRG9lIiwgImlhdCI6IDE1MTYyMzkwMjJ9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```

OAUTH 2

OAuth 2.0（开放授权 2.0）是一种用于授权的标准协议，允许用户通过第三方应用授权访问受保护的资源，而无需将自己的凭据（如用户名和密码）直接提供给第三方应用。OAuth 2.0 旨在提供一种安全的机制，允许用户授权第三方应用访问其在资源服务器上的资源，同时还能保护用户的凭据不被泄露。

OAuth 2.0 中涉及的一些重要概念和角色：

资源所有者（Resource Owner）：资源所有者是一个具有访问资源的用户或实体，通常是最终用户。
客户端（Client）：客户端是第三方应用，它请求访问受保护的资源。客户端可以是 Web 应用、移动应用或其他类型的应用。
授权服务器（Authorization Server）：授权服务器是负责验证资源所有者的身份并授予客户端访问权限的服务器。它会生成授权码（Authorization Code）或访问令牌（Access Token）。
资源服务器（Resource Server）：资源服务器是存储受保护资源的服务器，它需要验证传入请求的令牌并决定是否允许访问。

OAuth 2.0中的主要授权流程包括：

授权码授权流程（Authorization Code Flow）：此流程涉及的步骤如下：
- 客户端将用户重定向到授权服务器，携带请求授权的信息。
- 用户登录并同意授权。
- 授权服务器将授权码传递回客户端。
- 客户端使用授权码向授权服务器请求访问令牌。
- 授权服务器验证授权码，并颁发访问令牌给客户端。
隐式授权流程（Implicit Flow）：此流程适用于浏览器环境，其中访问令牌直接从授权服务器传递给客户端，而不需要授权码。
- 客户端将用户重定向到授权服务器，携带请求授权的信息。
- 用户登录并同意授权。
- 授权服务器将访问令牌直接传递给客户端，通过 URL 的哈希部分传递。
密码授权流程（Resource Owner Password Credentials Flow）：此流程允许用户将其凭据直接提供给客户端，然后客户端使用这些凭据向授权服务器请求访问令牌。这种流程适用于受信任的客户端，如原生移动应用。
客户端凭证授权流程（Client Credentials Flow）：此流程适用于客户端自身访问受保护的资源，而不是代表用户。客户端使用其自己的凭证向授权服务器请求访问令牌。

Session ID

Session ID 登录是一种传统的身份验证和会话管理方法，通常用于 Web 应用程序中。它是在 HTTP 协议的基础上实现的，用于跟踪用户的会话状态和认证信息。

在 Session ID 登录中，流程通常如下：

登录：用户提供用户名和密码进行登录。服务器验证用户凭据的有效性，如果验证通过，则会在服务器端创建一个新的会话（Session）。
Session ID：服务器为每个会话分配一个唯一的 Session ID（会话标识符），这个 ID 通常是一个随机生成的字符串。会话 ID 是存储在服务器上的数据结构，用于存储与会话相关的信息，如用户 ID、角色、权限等。
Cookie：服务器将会话 ID 发送给客户端浏览器，通常以 Cookie 的形式。浏览器会在每次请求中自动附带这个会话 ID，以便服务器能够识别用户的会话。
会话状态：服务器使用会话 ID 来查找对应的会话数据，以判断用户的认证状态和访问权限。用户在同一个会话中进行的操作和数据都可以被跟踪和维护。
登出：当用户主动登出或会话超时时，会话数据会被销毁，对应的会话 ID 也会失效。

Session ID 也存在一些缺点和安全隐患：

会话管理：服务器需要维护会话状态，可能占用服务器资源，尤其是在大量用户同时在线时。
安全性：如果会话 ID 被劫持，攻击者可以冒充用户的身份。为了防止这种情况，会话 ID 需要进行安全的传输（如使用 HTTPS）以及安全的生成和存储。
单点故障：如果服务器崩溃或重启，用户的会话状态可能会丢失。
扩展性：在分布式系统中，要确保会话在不同服务器之间共享和同步可能会增加复杂性。

PREVIOUS使用 Jekyll 搭建 Github Pages 记录

NEXTJavaScript 之 using 关键字