JWT(JSON Web Token)의 원리와 활용에 대한 심층 분석

이 글에서는 JWT에 대한 관련 지식을 주로 소개합니다. JWT의 원리와 사용법은 무엇입니까? 관심 있으신 분들은 아래 내용을 살펴보시고 모두에게 도움이 되었으면 좋겠습니다.

JSON Web Token(약칭 JWT)은 현재 가장 널리 사용되는 도메인 간 인증 솔루션입니다. 이 기사에서는 그 원리와 사용법을 소개합니다.

1. 교차 도메인 인증 문제

인터넷 서비스는 사용자 인증과 분리될 수 없습니다. 일반적인 과정은 다음과 같습니다.

1. 사용자가 사용자 이름과 비밀번호를 서버로 보냅니다.

2. 서버 확인이 완료되면 사용자 역할, 로그인 시간 등과 같은 관련 데이터가 현재 세션에 저장됩니다.

3. 서버는 사용자에게 session_id를 반환하고 이를 사용자의 쿠키에 기록합니다.

4. 사용자가 이후에 요청할 때마다 쿠키를 통해 session_id가 서버로 다시 전달됩니다.

5. 서버는 session_id를 받아 이전에 저장된 데이터를 찾아 사용자의 신원을 알아냅니다.

이 모델의 문제점은 확장성이 좋지 않다는 것입니다. 물론 단일 머신에서는 문제가 없습니다. 서버 클러스터이거나 크로스 도메인 서비스 지향 아키텍처라면 세션 데이터 공유가 필요하며 각 서버는 세션을 읽을 수 있습니다.

예를 들어 A사이트와 B사이트는 같은 회사의 관련 서비스입니다. 이제 사용자가 웹사이트 중 하나에 로그인하기만 하면 다른 웹사이트를 방문할 때 자동으로 로그인됩니다. 이를 어떻게 달성할 수 있습니까?

한 가지 해결책은 세션 데이터를 유지하고 이를 데이터베이스나 다른 지속성 계층에 쓰는 것입니다. 요청을 받은 후 다양한 서비스는 지속성 계층에서 데이터를 요청합니다. 이 솔루션의 장점은 구조가 명확하다는 점이지만, 작업량이 상대적으로 많다는 것이 단점이다. 또한 지속성 계층이 실패하면 단일 실패 지점이 됩니다.

또 다른 해결책은 서버가 단순히 세션 데이터를 저장하지 않는다는 것입니다. 모든 데이터는 클라이언트에 저장되고 각 요청에 대해 서버로 다시 전송됩니다. JWT는 이 솔루션의 대표자입니다.

2. JWT의 원칙

JWT의 원칙은 아래와 같이 서버가 인증한 후 JSON 개체를 생성하여 사용자에게 다시 보내는 것입니다.

{
  "姓名": "张三",
  "角色": "管理员",
  "到期时间": "2018年7月1日0点0分"
}

향후에는 사용자가 서버와 통신할 때 이 JSON 개체가 다시 전송됩니다. 서버는 사용자를 식별하기 위해 이 개체에만 의존합니다. 사용자가 데이터를 조작하는 것을 방지하기 위해 서버는 이 개체를 생성할 때 서명을 추가합니다(자세한 내용은 아래 참조).

서버는 세션 데이터를 저장하지 않습니다. 즉, 서버가 상태 비저장 상태가 되어 확장이 더 쉬워집니다.

3. JWT

실제 JWT의 데이터 구조는 아마도 다음과 같을 것입니다.

가운데 점(.)으로 세 부분으로 구분된 긴 문자열입니다. JWT 내부에는 줄 바꿈이 없습니다. 표시의 편의를 위해 여러 줄로 작성됩니다.

JWT의 세 부분은 다음과 같습니다.

• Header(head)

• Payload(payload)

• Signature(signature)

아래와 같이 한 줄로 작성합니다.

Header.Payload.Signature

다음은 이 세 부분을 차례로 소개하겠습니다.

3.1 Header

Header 부분은 JWT의 메타데이터를 기술하는 JSON 객체로, 일반적으로 다음과 같습니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

위 코드에서 alg 속성은 서명 알고리즘(알고리즘)을 나타내며 기본값은 HMAC SHA256(HS256으로 작성)입니다. typ 속성은 토큰(토큰)의 유형을 나타내며 JWT 토큰은 균일합니다. JWT로 작성되었습니다.

마지막으로 Base64URL 알고리즘을 사용하여 위 JSON 개체를 문자열로 변환합니다(자세한 내용은 아래 참조).

3.2 페이로드

페이로드 부분은 전송해야 하는 실제 데이터를 저장하는 데 사용되는 JSON 개체이기도 합니다. JWT는 선택을 위해 7개의 공식 필드를 지정합니다.

• iss(발급자): issuer

• exp(만료 시간): 만료 시간

• sub(제목): subject

• aud(청중): Audience

• nbf(이전 아님) ): 유효 시간

• iat(발급 시간): 발급 시간

• jti(JWT ID): 번호

이 섹션에서는 공식 필드 외에도 비공개 필드를 정의할 수도 있습니다. 예 .

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

JWT는 기본적으로 암호화되지 않으며 누구나 읽을 수 있으므로 이 섹션에 비밀 정보를 입력하지 마세요.

이 JSON 개체도 Base64URL 알고리즘을 사용하여 문자열로 변환해야 합니다.

3.3 서명

서명 부분은 데이터 변조를 방지하기 위해 처음 두 부분의 서명입니다.

먼저 비밀을 지정해야 합니다. 이 키는 서버에만 알려져 있으며 사용자에게 유출될 수 없습니다. 그런 다음 Header에 지정된 서명 알고리즘(기본값은 HMAC SHA256)을 사용하여 다음 수식에 따라 서명을 생성합니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

3.4 Base64URL

前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

四、JWT 的使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

五、JWT 的几个特点

（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。

（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。

（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。

（4）JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

推荐学习：《JavaScript视频教程》

위 내용은 JWT(JSON Web Token)의 원리와 활용에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!