TIL 43 (token-based authentication, jwt) (2021.11.23)

히스토그램(histogram)은 표(도수 분포표, 빈도표)로 되어 있는 도수 분포(frequency distribution)를 정보 그림으로 나타낸 것입니다.
예를 들어, 대학교의 한 학과에서 신입생들의 현재 거주 지역을 조사한 결과가 다음과 같다고 가정해 봅시다.
서울 2명, 경기 1명, 대전 4명, 부산 5명, 대구 1명, 광주 3명, 제주도 3명...
이 자료를 히스트그램으로 나타내면 각각 높이 2, 1, 4, 5, 1, 3, 3인 직사각형이 왼쪽부터 그려지게 됩니다. 
편의상 직사각형의 너비는 1이라고 가정합니다.// 이 히스토그램 내에서 만들 수 있는 가장 큰 직사각형의 면적은 8입니다 (O로 표시한 부분).
이처럼 임의의 히스토그램 내에서 가장 큰 직사각형의 면적을 리턴해야 합니다.

해당 문제에 대해서 아직 이해를 못해서 레프런스를 본 후, 다시 올리도록 하겠습니다.

---

What Is Token-based Authentication? 출처

Token-based authentication은 암호화된 보안 토큰을 생성하는 프로토콜입니다. 이를 통해 사용자는 웹 사이트에 자신의 신원을 확인할 수 있으며, 암호화된 고유 인증 토큰을 생성할 수 있습니다. 이 토큰을 사용하면 사용자 이름과 암호를 다시 입력할 필요 없이 제한된 기간 동안 보호된 페이지 및 리소스에 접근할 수 있습니다.

Token-based authentication은 다음과 같은 5단계 프로세스를 통해 작동합니다.

1. 요청: 사용자는 서버 또는 보호된 리소스에 대한 액세스 요청을 발급하는 로그인 자격 증명을 사용하여 서비스에 로그인합니다.

2. 확인: 서버는 로그인 정보를 확인하여 사용자에게 액세스 권한이 있는지 확인합니다. 여기에는 입력한 암호를 제공된 사용자 이름과 비교하여 확인하는 작업이 포함됩니다.

3. 토큰 제출: 서버는 특정 기간 동안 사용자를 위해 서명된 보안 인증 토큰을 생성합니다.

4. 저장소: 토큰은 사용자의 브라우저로 다시 전송되며, 이 브라우저는 향후 웹사이트 방문에 대한 접근을 위해 토큰을 저장합니다. 사용자가 새 웹 사이트에 액세스하면 인증 토큰이 디코딩되고 검증됩니다. 일치하는 항목이 있으면 사용자는 계속 진행할 수 있습니다.

5. 만료: 토큰은 사용자가 로그아웃하거나 서버를 닫을 때까지 활성 상태로 유지됩니다.

 

이 Token-based authentication는 사용자가 새 사이트로 이동할 때마다 신원을 확인할 필요 없이 애플리케이션, 웹 사이트 및 리소스에 대한 액세스를 제공받았음을 증명합니다. 웹 사이트는 사용자가 자신의 신원을 반복적으로 증명하도록 강요하지 않고 기존 암호 외에 추가적인 보안 계층을 추가할 수 있으므로 사용자 경험과 보안이 모두 향상됩니다.

What is JSON Web Token?

 

JSON 웹 토큰(JWT)은 당사자 간의 정보를 안전하게 전송하기 위한 컴팩트하고 독립적인 방법을 JSON 개체로 정의하는 개방형 표준(RFC 7519)입니다. 이 정보는 디지털 서명되어 있기 때문에 검증되고 신뢰할 수 있습니다. JWT는 비밀(HMAC 알고리즘)을 사용하거나 RSA 또는 ECDSA를 사용하여 공개/개인 키 쌍을 사용하여 서명할 수 있습니다.

 

JWT는 당사자 간 기밀을 제공하기 위해 암호화될 수 있지만, 우리는 서명된 토큰에 초점을 맞출 것입니다. 서명된 토큰은 그 안에 포함된 클레임의 무결성을 확인할 수 있는 반면 암호화된 토큰은 다른 당사자에게 이러한 클레임을 숨깁니다. 공개/개인 키 쌍을 사용하여 토큰에 서명할 경우 개인 키를 보유한 당사자만 서명했음을 인증합니다.

 

JWT 구조

JWT는 위 그림과 같이 . 으로 나누어진 3부분이 존재합니다.

 

Header

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

 

이 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성됩니다.

Header는 이것이 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 sign(암호화) 할지가 적혀있습니다. JSON Web Token이라는 이름에 걸맞게 JSON 형태로 이런 형태를 보실 수 있습니다.

 

Payload

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

첫 번째 부분과 마찬가지로, 위 JSON 객체를 base64로 인코딩하면 JWT의 두 번째 블록이 완성됩니다.

 

Payload에는 정보가 담겨 있습니다. 어떤 정보에 접근 가능한지에 대한 권한을 담을 수도 있고, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 암호화 시킵니다. 물론 암호화(헤더에서 정의한)가 될 정보지만, 민감한 정보는 되도록 담지 않는 것이 좋습니다.

 

Signature

HMAC SHA256 알고리즘(암호화 방법 중 하나)을 사용한다면 signature는 아래와 같은 방식으로 생성됩니다.

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

base64로 인코딩된 첫 번째, 그리고 두 번째 부분이 완성되었다면, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화합니다. base64 인코딩을 한 값은 누구나 쉽게 디코딩할 수 있지만, 서버에서 사용하고 있는 비밀키를 보유한 게 아니라면 해독해 내는데 엄청난 시간과 노력이 들어갈 겁니다!

 

---

JWT의 종류

1. Access Token
2. Refresh Token

Access token은 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용합니다. 클라이언트가 처음 인증을 받게 될 때(로그인 시), access, refresh token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 access token입니다.

 

Access token의 유효기간이 만료된다면 refresh token을 사용하여 새로운 access token을 발급받습니다. 이때, 유저는 다시 로그인할 필요가 없습니다.

---

토큰기반 인증 절차

토큰기반 인증의 장점

1. Statelessness & Scalability (무상태성 & 확장성)
   • 서버는 클라이언트에 대한 정보를 저장할 필요 없습니다 (토큰 해독이 되는지만 판단합니다)
   • 클라이언트는 새로운 요청을 보낼 때마다 토큰을 헤더에 포함시키면 됩니다
     • 서버를 여러 개 가지고 있는 서비스라면 더더욱 빛을 발휘합니다 (같은 토큰으로 여러 서버에서 인증 가능)
2. 안전하다
   • 암호화 한 토큰을 사용하고, 암호화 키를 노출할 필요가 없기 때문에 안전합니다
3. 어디서나 생성 가능하다
   • 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없습니다
   • 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰 관련 작업을 맡기는 것 등 다양한 활용이 가능합니다
4. 권한 부여에 용이하다
   • 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정할 수 있습니다
     • ex) 서비스의 사진과 연락처 사용 권한만 부여