지난 쿠키와 세션에 이어서 토큰 방식의 인증과 인가 구현 방법 중 JWT에 대해 공부하는 포스트
사용자가 자신의 아이덴티티를 확인하고 고유한 액세스 토큰을 받을 수 있는 프로토콜. 사용자는 토큰 유효 기간 동안 동일한 웹페이지나 앱, 혹은 그 밖에 해당 토큰으로 보호를 받는 리소스로 돌아갈 때마다 자격 증명을 다시 입력할 필요 없이 토큰이 발급된 웹사이트나 앱에 액세스할 수 있다.
인증 토큰은 도장이 찍힌 티켓이라고 생각할 수 있다. 토큰이 유효하다면 사용자는 계속해서 액세스할 수 있다. 사용자가 로그아웃하거나 앱을 종료하면 토큰도 무효화된다.
토큰 기반 인증은 비밀번호 기반 또는 서버 기반 인증 기법과는 다르다. 토큰이 두 번째 보안 계층을 제공하여 관리자가 각 작업과 트랜잭션을 정밀하게 제어할 수 있다.
토큰 인증 방식에서는 보조 서비스를 통해 서버 요청을 확인해야한다. 확인이 완료되면 서버가 토큰을 발급하여 요청에 응답한다.
사용자는 여전히 적어도 한 개의 비밀번호 를 기억해야 하지만 토큰이 액세스 계층을 하나 더 제공하기 때문에 도용하거나 침투하기가 훨씬 더 어렵고 세션 레코드가 서버에서 공간을 전혀 차지하지 않는다.
모든 인증 토큰이 액세스를 허용하지만 각 유형마다 약간씩 차이가 있다.
일반적으로 다음과 같은 세 가지 유형의 인증 토큰이 있다.
위의 세 가지 시나리오 모두 사용자가 무언가를 해야만 프로세스가 시작된다. 비밀번호를 입력해야 할 수도 있고, 혹은 질문에 답변해야 할 수도 있다. 하지만 예비 단계를 완벽하게 마쳤다고 해도 액세스 토큰이 없으면 액세스할 수 없다.
JWT는 Json Web Token의 약자로 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다. 웹 상에서 정보를 Json형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 string 형태로 저장되어있다. 누구나 복호화를 할 수는 있지만 약속된 Secret Key가 없다면 수정이 불가능한 읽기 전용 데이터다.
헤더, 페이로드, 서명의 세가지 부분으로 나누어져 있다.
{
"alg": "HS256",
"typ": "JWT"
}
어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것 인지에 대한 정보가 들어있다.
{
"sub": "1234567890",
"username": "카즈하",
"admin": true
}
전달하려는 정보(사용자 id나 다른 데이터들, 이것들을 클레임이라고 부른다)가 들어있다.
payload에 있는 내용은 수정이 가능하여 더 많은 정보를 추가할 수 있다. 그러나 노출과 수정이 가능한 지점이기 때문에 인증이 필요한 최소한의 정보(아이디, 비밀번호 등 개인정보가 아닌 이 토큰을 가졌을 때 권한의 범위나 토큰의 발급일과 만료일자 등)만을 담아야한다.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
가장 중요한 부분으로 헤더와 정보를 합친 후 발급해준 서버가 지정한 secret key로 암호화 시켜 토큰을 변조하기 어렵게 만들어준다.
한가지 예를 들어보자면 토큰이 발급된 후 누군가가 Payload의 정보를 수정하면 Payload에는 다른 누군가가 조작된 정보가 들어가 있지만 Signatute에는 수정되기 전의 Payload 내용을 기반으로 이미 암호화 되어있는 결과가 저장되어 있기 때문에 조작되어있는 Payload와는 다른 결과값이 나오게 된다.
이러한 방식으로 비교하면 서버는 토큰이 조작되었는지 아닌지를 쉽게 알 수 있고, 다른 누군가는 조작된 토큰을 악용하기가 어려워진다.