토큰 (Token)

: 유저 정보를 암호화(해싱)하여 클라이언트에 담는 것

토큰 기반 인증 (Token-based Authentication)

토큰은 유저 정보를 암호화하기 때문에 클라이언트에 담을 수 있다.
가장 범용적으로 쓰이는 토큰 인증 방식으로 JWT가 있다.

---

JWT (Json Web Token)

: JSON 포맷으로 사용자에 대한 속성을 저장하는 토큰

JWT의 종류

액세스 토큰(Access Token)

: 보호된 정보(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용되는 토큰

• 클라이언트는 처음 인증을 받을 때(로그인) 액세스 토큰과 리프레시 토큰 두 가지를 다 받지만, 실제로 권한을 얻는 데에 사용하는 토큰은 액세스 토큰이다.

리프레시 토큰(Refresh Token)

: 액세스 토큰의 유효기간이 만료되었을 때, 새로운 액세스 토큰을 발급받기 위해 사용하는 토큰

• 리프레시 토큰은 유효기간이 길기 때문에, 탈취되면 큰 문제가 발생할 수 있다.
• 따라서, 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 리프레시 토큰을 사용하지 않는 곳이 많다.

---

JWT의 구조

• JWT는 .으로 나누어진 세 부분이 존재하며, 각각 Header, Payload, Signature라고 부른다.
• JSON 형태로 정보가 담겨 있다.
  

1. Header

• 토큰의 종류 (e.g. JWT)
• 어떤 알고리즘으로 signature를 암호화(sign)할지

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

➡️ 이 JSON 객체를 base64 방식으로 인코딩하면, JWT의 첫 번째 부분인 Header가 완성된다.

---

2. Payload

• 유저의 정보 (e.g. 이름)
• 어떤 정보에 접근 가능한지에 대한 권한
• 기타 필요한 정보

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

➡️ 이 JSON 객체를 base64 방식으로 인코딩하면, JWT의 두 번째 부분인 Payload가 완성된다.
(payload는 디코딩이 쉬운 base64 방식으로 인코딩되기 때문에, 너무 민감한 정보는 담지 않는 것이 좋다.)

---

3. Signature

• Header, Payload를 base64로 인코딩한 값과 salt값의 조합으로 암호화된 값
• 서버의 비밀키(암호화에 추가할 salt)와 헤더에서 지정한 알고리즘을 사용하여 해싱한다.

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

➡️ 누군가 Header와 Payload를 알아내 토큰을 위조하더라도, 서버의 비밀 키(salt)까지 정확하게 알고있지 않은 한, 동일한 signature를 만들 수 없기 때문에 토큰을 위조할 수 없다.

---

JWT 사용 예시

JWT는 권한 부여에 굉장히 유용하다.

A라는 앱이 Gmail과 연동되어 이메일을 읽어와야 한다고 가정해보자.
1. Gmail 인증 서버에 로그인 정보(username, password)를 제공한다.
2. 성공적으로 인증시 JWT를 발급받는다.
3. A앱은 JWT를 사용해 해당 유저의 Gmail의 이메일을 읽거나 사용할 수 있다.

---

토큰기반 인증 절차

1. 클라이언트가 서버에 아이디 / 비밀번호를 담아 로그인 요청을 한다.
2. 서버는 아이디 / 비밀번호가 일치하는지 확인한 후, 클라이언트에게 보낼 암호화된 토큰을 생성한다.
   • 액세스 토큰 / 리프레시 토큰 모두 생성한다.
   • 토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처 등..)가 될 수 있다.
   • 두 종류의 토큰이 같은 정보를 담을 필요는 없다.
3. 서버가 토큰을 클라이언트에 보내주면, 클라이언트는 토큰을 저장한다.
   • 이때 토큰을 저장하는 위치는 Local Storage, Session Storage, Cookie, state 등 다양하다.
4. 클라이언트가 HTTP 헤더(Authorization 헤더) 또는 쿠키에 토큰을 담아 보낸다.
   • Authorization 헤더 - 참고1, 참고2
   • 쿠키 - 리프레시 토큰을 헤더, 액세스 토큰을 바디에 담는 등 다양한 방법으로 구현할 수 있다.
5. 서버는 토큰을 해독하여, 자신이 발급한 토큰이 맞다고 판단될 경우 클라이언트의 요청을 처리한 후 응답을 보내준다.

---

토큰 기반 인증의 장점

1. 무상태성(Statelessness) & Scalability(확장성)

• 서버는 클라이언트에 대한 정보를 저장할 필요가 없다. (서버, DB 부담 ↓)
• 클라이언트는 토큰을 헤더에 추가함으로써 인증절차를 완료할 수 있다.

2. 안정성

• 암호화한 토큰을 사용한다.
• 암호화 키를 노출할 필요가 없다.

3. 어디서나 생성 가능

• 토큰을 생성하는 서버가 꼭 토큰을 만들지 않아도 된다.

4. 권한 부여에 용이

• 토큰의 payload 안에 어떤 정보에 접근 가능한지 정의할 수 있다.
  e.g. 사진과 연락처 권한 부여 / 사진 권한만 부여 / 연락처 권한만 부여 등