Token

📝오늘 배운 내용

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

앞서 알아본 세션 기반 인증은 서버(혹은 DB)에 유저 정보를 담는 인증 방식이었다. 서버에서는 유저가 민감하거나 제한된 정보를 요청할 때마다 "지금 요청을 보낸 유저에게 우리가 정보를 줘도 괜찮은가?"를 확인하기 위해 가지고 있는 세션 값과 일치하는지 확인한다. 매 요청마다 데이터베이스를 살펴보는 것이 불편하고, 이 부담을 덜어내고 싶다면 토큰 기반 인증 중 대표적인 JWT (JSON Web Token)에 대해서 알아보자.

JWT의 구조

1. Header

• Header는 이것이 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign 할지 적혀있다. JSON 형태로 작성되어있다.

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

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

2. Payload

Payload에는 정보가 담겨있다. 어떤 정보에 접근 가능한지에 대한 권한을 담을 수도 있고, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 Sign 시킨다. Payload에는 민감한 정보는 되도록 담지 않는 것이 좋다.

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

3. Signature

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

만약 HMAC SHA256 알고리즘을 사용하면 signature는 아래와 같은 방식으로 생성된다.

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

토큰기반 인증 절차

• 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보낸다.
• 서버는 아이디/비밀번호가 DB에 있는 정보와 일치하는지 확인하고, 클라이언트에게 보낼 Signature 된 토큰을 생성한다.
• 토큰을 클라이언트에게 보내주면, 클라이언트는 토큰을 저장한다.
  저장하는 위치는 local storage, cookie, react의 state등 다양하다.
• 클라이언트가 HTTP 헤더에 토큰을 담아 보낸다.
  bearer authentication을 이용한다.
• 서버는 토큰을 해독하여 서버에서 발급해준 토큰이 맞을 경우 클라이언트의 요청을 처리한 후 응답을 보낸다.

토큰기반 인증의 장점

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

   • 서버는 클라이언트에 대한 정보를 저장할 필요가 없다.
   • 클라이언트는 새로운 요청을 보낼 때마다 토큰을 헤더에 포함시키면 된다.
     만약 여러개의 서버를 가지고 있는 서비스라면 같은 토큰으로 여러 서버에서 인증이 가능하다.

2. 안전하다.

   • signature를 받은 토큰을 사용하고 암호화 키를 노출할 필요가 없다.

3. 어디서나 생성 가능하다.

   • 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없다.
   • 토큰 생성용 서버를 따로 만들거나 다른 회사에서 토큰 관련 작업을 맡기는 것 등 다양한 활용이 가능하다.

4. 권한 부여에 용이하다.

   • 토큰의 payload 안에 어떤 정보에 접근 가능한지 정할 수 있다.