토큰(Token)

토큰 기반 인증을 사용하는 이유

세션기반 인증에선 새로운 클라이언트의 요청이 있을 때마다 서버는 매번 DB에서 확인한다. 이 부담을 덜어내기 위해 고안한 방법이 토큰 기반 인증이다.
대표적인 토큰 기반 인증은 JWT(Json Web Token)이 있다.

토큰?

우리 일상생활에서 아는 토큰은 아래와 같다.

• 오락실에서 사용하는 토큰
• 행사에 입장할 때 사용하는 토큰
• 놀이공원에 입장료를 내면 주는 토큰

즉, 각 시설에 맞는 토큰을 가지고 있으면 해당 시설을 이용할 수 있다.

토큰 기반 인증은 클라이언트에 인증 정보를 보관하는 방법으로 고안되었다. 클라이언트는 서버에게 토큰을 보여주고 다양한 기능을 요청할 수 있다.
중요한 건 클라이언트에 토큰을 그대로 담는 것이 아니라 암호화한 토큰을 담아야 한다는 것이다.

토큰 기반 인증의 장점

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

JWT(Json Web Token)

대표적인 토큰 기반 인증 기술이다. Json포맷으로 사용자에 대한 속성을 저장하는 웹 토큰이다. JWT는 2개의 종류가 있다.

• Access Token
• Refresh Token

Access Token

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

Refresh Token

그렇다면 access token만 있으면 되는 거 아닌가?

권한부여 받는데는 access token만 있으면 되지만, 만약 access token이 공격자로부터 탈취 당했다면 중요 정보가 공격자 손에 넘어가게 된다.
그걸 방지하기 위해 access token은 짧은 유효기간을 설정하는데, 이때 유효기간이 만료된다면 refresh token을 사용해 새로운 access token을 발급받는다. 그럼 사용자는 재로그인할 필요가 없다.

refresh token도 탈취 당한다면?

공격자가 access token이 만료될 때마다 새로 발급하기 때문에 큰 문제가 될 것이다. 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token을 사용하지 않는 곳이 많다. 따라서 Oauth, 쿠키, 세션 등등 각 방법들의 장단점을 참고하며 필요에 맞게 사용하는 것이 좋다.

JWT의 구조

JWT는 . 을 기준으로 세 부분으로 나뉜다.

1. Header

헤더는 이것이 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign(암호화) 할지가 적혀있다.

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

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

2. Payload

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

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

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

3. Signature

base64로 인코딩된 첫번째, 두번째 부분이 완성 되었다면, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다. base64 인코딩을 한 값은 누구나 쉽게 디코딩할 수 있지만, 서버에서 사용하고 있는 비밀키를 보유한게 아니라면 쉽게 해독하지 못한다.

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

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

JWT 흐름

1. 클라이언트➡️서버 // ID, 비밀번호를 입력해 로그인한다. (POST 요청)
2. 서버➡️데이터베이스 // 요청받은 ID, 비밀번호가 존재하는지 확인한다.
3. 서버 // 클라이언트에게 보낼 암호화된 토큰(access token, refresh token)을 생성한다. 토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처, 기타등등)이 될 수 있고, 두 종류의 토큰이 같은 정보를 담을 필요는 없다.
4. 서버➡️클라이언트 // 생성한 암호화된 토큰을 보낸다. 이때 클라이언트는 토큰을 local storage, cookie, react의 state 등등 다양한 곳에 저장할 수 있다.
5. 클라이언트➡️서버 // 토큰을 HTTP 헤더에 담아 보낸다. (GET 요청)
   ex) Headers: {Authorization: "Bearer JWT_TOKEN"}
6. 서버 // 클라이언트로부터 받은 토큰을 해독해 서버가 발급한 토큰이 맞는지 확인한다.
7. 서버➡️클라이언트 // 서버가 발급한 토큰이 맞는지 확인됐다면 원하는 요청 해결 & 응답을 보낸다.