2 분 소요

JWT 토큰

순서

1.인증과 인가

2.session

3.jwt Token

4.jwt Token보완

 

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

  • 인증(Authentication)

로그인

사이트에 가입된 회원임을 즉 특정 서비스에 일정 권한이 주어진 사용자임을 아이디와 패스워드를 통해 인증 받는다

  • 인가(Authorization)

인증을 받은 사용자가 서비스를 사용할 때 자신의 계정으로 로그인 사이트가 되어있음을 알아보고 허가 해주느것 (로그인이 유지되는 상태에서)

즉 사이트나 서비스에 사용자가 로그인하고 있는 사실을 서버가 인지하는 방법이다.

웹사이트 상의 링크는 클릭의 하나는 다 요청 이다 사이트는 무수한 사용자들의 요청에 응답을 해주고 있다

서버는 이러한 요청이 올때마다 로그인 인증 과정이 거친 상태인지 확인해서 로그인이 필요한 기능들에 허용을 할지 말지 결정해서 응답해야한다

인가의 방법에는 세션방식과 jwt 토큰 방식이 있다.


 

2.Session 방식

시간에 따라 바뀌는 어떤 상태값을 가진다 stateaful 하다고 한다.

세션은 반은 서버의 메모리에 반은 브라우저에 보낸다

(하드디스크나 DB에 넣기도 한다)

브라우저가 이표를 세션 id 란 이름의 쿠키(브라우저에 저장되는 정보)로 저장하고 사이트에 요청을 보낼때마다 세션을 실어보낸다

세션 id를 사용 해서 서버에 로그인이 되어있음이 지속 되는이상태를 세션이라고 한다

단점

사용자가 동시에 접속시 문제 발생한다.

서버가 재부팅 되면 메모리에 있는 문제이다.

서비스가 규모가 큰 경우 서버를 여러대를 두고 사이트르 운영할때 발생한다.

서버가 여러가지 일 경우 각자 서버를 가지고 있기 때문에 요청이 들어오면 로드밸런싱을 해줘야하는데 다른 서버는 메모리가 없기 때문에 사용자의 요청이 오면 로그인을 줄 수 없어 문제가 발생 한다

다른 방법: 데이터 베이스서버 와 레디스나 memcached 같은 메모리형 데이터 베이스 서버에 두기도 한다 (느림)


 

3.JWT TOKEN (JSON WEB ToKEN)

사용자가 로그인을 하면 세션과 같이 나누어 주는 것이 아닌 그냥 주는데 서버가 기억하지 않는다.

인코딩 또는 암호화된 3가지 데이터를 이어 붙힌 토큰은 마침표 기준 으로 나누어진다.

header, payload, verify signature로 구분 된다 (1.헤더, 2.페이로드, 3.서명)

 

페이로드부터 살펴보자

2.Payload

Base 64로 디코딩 하면 JSON형식으로 여러 정보들이 들어 있다.

토큰을 누가 발급하고 언제까지 유효한지 서비스가 사용자에게 토큰을 통해 공개 하기 원하는 내용(사용자의 닉네임,서비스상의레벨,관리자여부)이 들어있다.

이런 토큰에 담긴 사용자 정보등의 데이터를 Claim이라고 한다

사용자가 로그인을 하고 나서 정보들이 클레임으로 실려온다

사용자로부터 서버한테 보내지는거고 사용자가 받아서 가지고 있는 토큰 자체에 이런 정보들이 들어있으면 서버가 요청마다 일일이 데이터 베이스에서 뒤지는 일을 하지 않아도 된다

 

1.헤더

type 토큰의 타입인데 여기에는 언제나 jwt들어가며 고정값이다

다른 하나는 alg이다 알고리즘으로 여기에는 3번 서명값을 만드는데 사용될 알고리즘이 지정된다.

HS256 등 여러 암호화 방식 중 하나를 지정할 수 있다.

헤더와 페이로드 그리고 ‘서버에 감춰놓은 비밀값’ 셋을 암호화 알고리즘에 넣으면 서명 값이 된다.

(서버는 1,2번 값을 ‘서버의 비밀키’ 와 함께 돌려봐서 계산된 결과 값이 3번 서명값과 일치하는 결과가 나오는지 확인을 한다 만약 2번 페이로드의 정보가 서버가 아닌 누군가에 의해 조금이라도 수정 되었다면 당연히 맞지 않는다. 3번 서명값과 계산값이 일치하고 유효기간도 지나지 않았다면 그 사용자는 로그인 된 회원으로서 인가를 받는다)

시간에 따라 바뀌는 어떤 상태값을 안 갖는 걸 stateless 하다고 한다.

 

단점

stateaful한 세션 처럼 모든 상태를 기억하고 있는 것은 구현하기 부담되고 고려사항도 많지만 기억하는 상태들을 언제든 제어할 수 있다

한 기기에서만 로그인 가능한 서비스를 만들려고 하는경우 불가능하다

이미 줘버린 토큰을 뺏을 수 도 없고 그 토큰의 발급 내역이나 정보를 서버가 기록하지 않아 통제가 불가능하다.

토큰이 해킹당하면 무효화할 수 있는 방법 또한 없게 된다.

jwt로만 인가를 구현하는 곳은 많지 않다.


 

4.JWT TOKEN 보완하기

토큰 만료시간을 짧게 준다.

 

  • acess 토큰과 refresh 토큰

acess토큰: 30분

refresh 토큰: 2주

access 토큰과 refresh 토큰을 발급 하고 클라이언트에게 보내고 나서 refresh 토큰은 상응값을 데이터베이스에 저장한다.

access 토큰의 수명이 다하면 refresh 토큰을 보낸다.

서버는 그걸 데이터 베이스에 저장된 값과 대조해보고 맞다면 새 acess 토큰을 발급해준다.

refresh 토큰만 안전하게 관리되면 유효할 동안 access 토큰일 만료 될때마다 다시 로그인을 할 필요가 없이 발급 받을 수 있다.

그러나 완벽한 방법은 아니다. 내 서비스가 적합한지 알고 맞게 사용 해야한다.

댓글남기기