[네크워크] Token (토큰)

Session 기반의 인증은 매 HTTP 요청마다 해당 요청을 한 유저를 확인하기 위해 Session DB를 확인해야 하는 작업을 해줘야 한다. 모든 유저들에 대해 이러한 작업을 매번 하기에는 서버에 부담을 줄 수가 있다. 이러한 단점을 보완하기 위해 나온 것이 토큰 기반의 인증으로 JWT라고 한다.

JWT (JSON Web Token)

유저가 ID와 비밀번호로 임의의 웹사이트에 로그인을 시도하면 해당 ID와 비밀번호가 서버로 보내진다. 그리고 서버에서는 ID와 비밀번호를 확인해서 비밀번호가 맞다면 Session과는 다르게 DB에 Session ID를 생성하지 않는다. 대신에 유저의 정보와 Signature 알고리즘을 통해서 Signed 정보를 문자열의 형태로 클라이언트에 보낸다. 여기서 Signed 된 문자열의 형태가 Token이다.

 

다음 요청 때 Token을 같이 보내서 서버에서는 해당 Token이 유효한지 확인을 한 다음에 요청한 유저가 누구인지를 확인한다.

JWT 구조

JWT는 세 가지 부분으로 나뉘고 각각 header, payload, signature라고 불린다.

header

JSON 객체를 base64로 인코딩을 해서 생성을 한다. 여기에는 2가지 정보가 있다.

 

• typ: Token의 타입으로 항상 JWT가 들어간다.
• alg: 알고리즘의 약자로 signature 값을 생성할 때 사용하는 알고리즘을 지정한다. (HS256, 등등)

payload

JSON 객체를 base64로 인코딩을해서 생성을 한다. 여기에는 Token에 대한 정보(누가 발급했는지, 언제까지 유효한지 등등), 유저의 접근권한 정보, 유저의 이름 등등의 정보가 담겨있다. 이러한 정보들은 base64로 인코딩 되었을 뿐, 암호화되지는 않았기 때문에 누구나 디코딩해서 정보를 볼 수 있기 때문에 비밀번호와 같은 민간함 정보들은 담지 않는다.

signature

header, payload 그리고 서버에만 저장되어있는 비밀키를 사용해서 header에서 지정한 암호화 알고리즘을 돌려서 생성한 값이다. 서버에서는 Token을 받았을 때 header, payload 그리고 비밀키를 사용해서 signature와 동일한 값이 나오는지를 확인해서 해당 Token이 조작이 된 것인지 아닌지를 판단한다.

장점

• 데이터베이스가 따로 필요하지 않다.
• 어디에서나 Token을 생성할 수 있다. Token을 확인하는 서버가 Token을 만들 필요가 없다.

단점

• Token을 추적하지 않기 때문에 (Stateless), 유저에 대한 통제가 없다. 예를 들어, 여러 기기에서 로그인이 된 상태인데, 모든 기기에서 강제 로그아웃 같은 기능을 구현할 수 없다.
• 만약 Token이 탈취당했을 때 해당 Token을 무효화할 수 있는 방법이 없다. 이러한 단점을 보완하기 위해 Access Token, Refresh Token이 사용되기도 한다.