JWT 토큰을 이용한 로그인 방법 이해

JWT 토큰을 이용해 로그인 기능을 구현하기 앞서 구글링을 통하여 해당 방법을 이해하기 위해 글을 써봅니다.

 

인증과 인가

인증(Authentication)

사용자가 누구인지 확인하는 과정. (ex. 로그인)

 

인가(Authorization)

사용자에 대해 자원 접근 권한같은 것을 허락하는 것. (ex. 카페 등급별 게시물)

 

 

HTTP

HTTP는 비연결성 및 무상태성이라는 특징을 가지는 프로토콜이다. 즉, 요청을 처리하고 난 후에는 요청을 한 클라이언트의 어떠한 정보도 남기지 않는다. 이러한 특징 덕분에 서버는 많은 클라이언트와의 연결을 유지하지 않아 서버의 자원도 아끼고 부담도 적다.

 

그러나, 연결을 유지하지 않기 때문에 방금 전 요청한 클라이언트가 다시 요청을 보내도 이전에 요청한 클라이언트인지 구분하지 못한다. 그래서 로그인을 통해 어떤 사용자가 인증되었어도 다음 요청에 서버는 그것을 기억하지 못해 클라이언트가 다시 로그인해야 되는 상황이 생겨버린다.

 

이를 해결하기위한 방법으로 Cookie와 Session을 이용했다.

 

 

Cookie와 Session

Cookie

쿠키란 서버에서 클라이언트의 컴퓨터(웹 브라우저)에 저장하는 작은 정보 파일이다. Key-Value 형식의 문자열로 구성되며, 응답 헤더 속 Set-Cookie 속성에 쿠키를 담아 보낸다. 여러 개의 쿠키를 보내고 싶다면 Set-Cookie 속성을 여러 개 넣으면 된다. 서버는 클라이언트의 상태 정보를 쿠키로 보내어 이를 필요시 활용한다.

 

로그인을 예시로 보통 우리는 어떤 웹 사이트에서 로그인을 하면 그 이후에는 다시 ID와 패스워드의 입력없이 로그인 된 상태에서 할 수 있는 작업들을 할 수 있다. 이것이 가능한 이유는 서버에서 로그인에 대한 요청을 응답할 때 클라이언트에 저장하고 싶은 정보들을 응답헤더 속 쿠키에 담아 보내기 때문이다. 그러면, 이후에 클라이언트가 요청 시마다 요청헤더 속 Cookie에 서버가 보낸 쿠키가 자동으로 담겨 해당 서버로 보내진다.

 

이를 통해 서버는 쿠키를 검사하고 해당 사용자가 인증되었던 사용자인지 판단하고 로그인 된 상태를 유지시켜 주는 것이다.

 

하지만, 매번 쿠키를 통해 사용자를 '인증'하는 작업은 다음과 같은 단점이 있다.

• 쿠키는 노출 시 해당 데이터가 그대로 노출된다.
• 쿠키는 쉽게 편집해서 보낼 수 있다.
• 데이터 크기가 제한적이다.

 

Session

그래서 나온 것이 바로 Session이다. 실상 쿠키로 유저의 정보를 주고받는다는 전제는 동일하다. 하지만, 세션은 각 클라이언트 별로 Session ID라는 것을 부여해 이를 서버에 저장해두고 쿠키로 전달해 클라이언트가 요청 시 전달할 수 있도록 한다.

 

Session ID는 서버에서 관리하며 일정 시간 혹은 새로운 접속 시마다 다르게 할당되기 때문에 기존의 유저 정보만을 전달받던 쿠키보다는 안전하다는 장점이 있다. 하지만, 서버에서 이런 세션 정보들을 관리하기 때문에 서버가 유저 정보에 더해서 세션 ID를 저장해야한다는 부담이 있다.

 

 

JWT

JWT는 Json 객체에 인증에 필요한 정보들을 담아 암호화 시킨 토큰을 의미한다.

JWT 토큰을 HTTP 헤더나 URL 파라미터에 실어 보냄으로써 사용자에 대한 인가, 인증 과정을 구현할 수 있다. Session ID와 달리 개인키를 통한 전자서명이 들어가기 때문에 보안이 위의 두 방법보다 뛰어나다.

 

JWT 구조

JWT 토큰 구조 (jwt.io)

JWT는 . 을 구분자로 3가지로 나누어진다.

Header.Payload.Signature

 

Header에는 토큰의 타입과 해싱 알고리즘을 지정한다. 해싱 알고리즘이 나중에 Signature부분에서 사용되는 알고리즘을 의미한다.

Payload에는 서버에서 담고자하는 사용자 권한 정보 및 데이터가 담겨있다.

Signature에는 Header와 Payload를 Base64로 인코딩하여 이 값들을 Header 속 해싱 알고리즘과 비밀 키로 암호화한 값이 담긴다.

 

정보 ㅡ payload

payload에는 서버가 토큰에 담을 정보들이 있다. 담는 정보의 한 조각을 클레임(claim)이라고 부르며 이는 name: value 꼴로 되어있다. 위의 사진에서 "sub": "1234567890"이 하나의 클레임이 되는 것이다.

 

클레임 종류는 크게 3가지로 나뉜다.

1. registered
2. public
3. private

 

registered

registered 클레임들은 서비스에 필요한 정보가 아닌 토큰에 대한 정보를 담는 즉, 이미 약속되어 이름이 정해진 클레임들이다.

• iss : 토큰 발급자
• sub : 토큰 제목
• aud : 토큰 대상자
• exp : 토큰 만료 시간
• nbf : 토큰 활성 날짜
• iat : 토큰 발급 시간
• jti : JWT의 고유 식별자

 

public

해당 클레임은 충돌이 방지된 이름을 갖고 있어야 하며 이를 위해 클레임 이름을 URI 형식으로 짓는다.

 

private

비공개 클레임은 사용자 정의 클레임이며, 서버와 클라이언트 사이에 약속된 정보를 저장한다.

 

서명 ㅡ signature

이 값은 헤더와 정보를 각각 base64로 인코딩한 후 둘 값을 합해 비밀키로 해시 알고리즘을 거쳐 생성한다. 위의 사진대로 다음과 같은 방식으로 만들어진다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secretKey
)

 

그리고 해당 해시 알고리즘을 통해 나온 값을 base64로 인코딩 하여, 맨 뒤에 붙여주는 것이다. 이 서명을 통해 JWT 토큰에 대한 유효성 검증을 이루어낸다. 그렇게해서 최종적으로 이런 형태의 JWT 토큰이 하나 만들어진다.

 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

근데 토큰이 만들어지는 과정을 보면 결국 Payload에 대한 부분이 base64로 인코딩 되어있을 뿐 노출되어 있다는 것을 알 수 있다. 그렇기 때문에 payload에는 중요한 데이터를 넣지 않아야한다. 또한, 쿠키나 Session ID에 비해 토큰의 길이가 상당히 긴 것을 확인할 수 있다. 즉, 정보가 많아질 수록 토큰의 길이가 늘어나 부담이 될 수 있다.

 

JWT 과정

1. 사용자가 아이디, 비밀번호와 함께 로그인 요청을 보낸다.
2. 서버는 해당 아이디와 비밀번호가 DB에서 일치하는지 확인한다.
3. 일치한다면 서버는 비밀 키로 json 객체를 암호화해 JWT 토큰을 발급한다.
4. JWT 토큰을 헤더에 담아 클라이언트로 보낸다.
5. 클라이언트는 이를 저장해두었다가 요청 시마다 JWT 토큰을 함께 보낸다.
6. 서버는 매번 헤더를 확인해 서버에서 발행한 토큰인지 확인하는 과정을 거쳐 사용자의 요청을 응답한다.

 

헤더에 넣어보낼 때에는 Authorization 헤더에 담아 보낸다. bearer를 앞에 붙여주는데 이는 JWT 토큰 또는 OAuth 토큰 인증 방식을 사용한다는 의미이다.

{
  "Authorization": "Bearer " + {토큰 값}
}