[WEB] 토큰 (Token)

1. 인증(Authentication)과 인가(Authorization)

인증과 인가는 언뜻 비슷하지만 명확히 다른 단어이다.

 

인증은 '로그인' 그 자체이라고 생각하면 된다.

즉, 사이트에 특정 권한을 가진 사용자임을 고유 ID, pw 등을 통해서 인증을 받는 것이다.

 

인가는 로그인이 '유지되는 상태에서 일어나는 일'이다.

인증을 받은 사용자가 사이트 내에서 '자신의 계정으로만' 할 수 있는 활동을 할 때 사이트에서 허가하는 것을 의미한다.

 

사용자가 자기 계정을 사용하려할 때 어센틱케이쎤!!
응 어서와라이제이션~  -얄코쌤

 

 

---

2. JWT(JSON Web Token)

1) 서버에서 알아야하는 것은?

JWT는 인가에 관련된 기술이다.

어떤 사이트를 사용자가 이용할 때에는 '해당 유저가 로그인한 상태인지 아닌지' 를 서버가 알 수 있는 방법이 필요하다.

 

먼저, 사이트 내 서비스를 사용자들이 이용할 때는 모든 것이 다 요청이다. 그리고 사이트는 그 요청에 대한 응답을 한다.

이때 서버는 요청마다 로그인 여부를 확인한 후, 특정 서비스의 제공을 허용할 지 안 할지를 결정한다.

 

매 요청마다 서버에 유저 아이디, 비번 정보 자체를 전송하기에는 로그인 작업이 너무 무거운 작업이다.

(DB에 저장된 아이디 계정과 비밀번호를 처리한 값이 입력값과 일치하는가? 등의 처리)

또한 보안 상의 우려도 존재한다.

 

2) 세션

인가를 처리하는 방식 중 세션을 활용하는 방법은 '세션 표딱지'를 유저와 서버가 서로 나누어 가지며

요청이 서버에 들어왔을 때 이를 이용하여 인가를 확인한다.

 

그러나 이 방식은 사용자 수에 따른 용량 부족과 서버 재부팅 시 저장된 자료가 증발하는 문제가 있다.

그에 따라 모든 사용자 로그인이 튕기는 경우가 발생하기도 한다.

 

더 문제는 서비스의 규모가 커서 서버 Com을 여러 대 두고 운영할 때인데

각 Com간의 정보 공유 문제로 세션 유지가 어렵다는 문제가 발생할 수 있다.

 

만약 메모리가 아닌 서버, DB 등에 저장할 경우에는 속도 저하의 문제가 있다.

 

정리하면 세션은 서버가 복잡한 구성과 환경에서 어떤 상태를 기억해야한다는 오버헤드가 발생한다.

 

3) JWT의 등장

JWT는 세션의 단점을 극복하고 '인가'를 처리하기위해 고안된 '토큰 방식'이다.

이를 사용하는 서비스에는 사용자가 로그인을 하면 토큰을 출력해서 전달한다.

 

세션이 서버가 반을 갖고 나머지 반을 주었다면

JWT는 사용자에게 온전히 전달한다. 이것이 세션과 다른점이다.

 

코드의 형태는 인코딩 혹은 암호화된 3가지 데이터를 이어붙인 것이다.

ex) eyJhbGciOiJIUzI.eyJzdWIiOyfQ.SflKxwReJf366yJV_adQssw5c (임의 예시) 
https://jwt.io/

 

JWT 구성

위의 예시를 보면 ' . ' 두개로 3부분으로 나뉜 것을 알 수 있다.

각각의 이름은 header(헤더), payload(페이로드), verify signature(서명) 이다.

 

①

payload는 사용자 정보 등의 데이터인 Claim을 담는다.(누가 누구에게 제공, 유효기간, 닉네임, 관리자 여부 등 서비스가 담고 싶은 것들)

즉, 사용자가 로그인을 하고 받는 토큰 내에 Claim이 담겨 있고

사용자가 요청을 보낼 때마다 서버로 토큰을 보내면서 이번에는 사용자에서 서버로 데이터가 전달되는 것이다.

 

이러한 방식은 토큰 자체에 필요할 정보들이 들어있기 때문에 DB 내에서 정보 검색 시간이 줄어든다.

 

②

그렇다면 이 정보의 암호화는 어떻게 진행할까?

 

먼저 header는 type과 alg으로 이루어지는데

type은 jwt로 고정이고 alg는 verify signature의 값으로 사용될 알고리즘이다. HS256 등 여러 암호화 방식 중 하나를 지정한다.

 

헤더와 페이로드, 서버에 내장된 암호키를 알고리즘에 넣어서 나온 값이 바로 verify signature값이다.

외부사용자는 서버에 내장된 암호키를 알지 못한다면 토큰을 통해서는 정보들을 조작할 수 없다.

 

서버는 사용자의 요청에 담긴 토큰의 header와 payload 값을 서버의 비밀 키와 함께 알고리즘을 돌리고

반환된 값이 verify signature값과 일치하는지를 검토한다.

 

만약 일치하지 않는다면 접근을 거부하고

일치하고 유효기간까지 문제없다면 로그인된 유저로 인가를 내준다.

 

 

4) 세션과 JWT의 단점

JWT가 세션을 완벽하게 대체할 수 있는 것은 아니다!

세션은 stateful하고, JWT는 stateless하다. 즉, 동적이고 정적이다.

 

세션의 경우 모든 사용자들의 상태를 기억해야한다는 것이 단점이지만

이것이 해결이 될 경우 기억해야할 대상의 상태를 언제든 제어할 수 있다.(무효화 등이 가능함)

 

이에 대한 예시로 만약 로그인할 기기가 한 대만 유지되도록 하기위해서

세션 방식을 활용할 경우 새로운 기기가 로그인을 시도할 때 로그인된 기기는 로그아웃이 되도록

기존 세션을 종료하면 된다.

 

반대로 토큰의 경우에는 한 번 발급이 된다면 서버에서는 대상의 정보를 가지고 있지 않기 때문에

통제하는 것이 어렵다. 심지어 이를 악용하여 토큰을 악성 유저가 활용할 경우 이를 제지할 수 있는 방법이 없다.

 

따라서 많은 서비스들이 JWT와 세션을 적절히 분배하여 사이트를 만든다.

 

 

5) 토큰의 단점을 보완하는 방법

이러한 토큰의 단점을 보완하기 위해서 고안한 방법 중 하나는 로그인 시 2개의 토큰을 부여하는 것이다.

수명이 몇 시간 혹은 몇 분 이하로 짧은 access 토큰과

보통 2주 정도의 긴 수명을 가지는 refresh 토큰이다.

 

이 방식을 구현하는 방식 중 하나는

두 토큰을 발급하고 클라이언트에게 보내고 나서 refresh 토큰의 상응값을 DB에도 저장한다.

 

사용자는 access 토큰의 수명이 다하면 refresh 토큰을 보내는데

서버가 DB에 저장된 값과 비교해보고 맞다면 새로운 access 토큰을 발급해주는 것이다.

refresh 토큰이 안전하게 관리된다면 이것의 유효기간 동안은 로그인을 새로하지 않고도 access 토큰을 발급받을 수 있는 것이다.

 

이 방식은 access 토큰이 누군가에게 탈취되어도 그것이 금방 무용지물이 되고

강제 로그아웃을 시키기 위해서 refresh토큰을 db에서 삭제하여 access토큰 갱신이 더이상 불가하도록 하면 된다.

 

물론 짧은 시간 access 토큰이 유지되는 동안 이를 막을 수 있는 방법은 없다. 그러나 토큰 하나로 운영하는 것보다 좋음