Stateful / Stateless / JWT

Stateful

 서버는 클라이언트에서 요청을 받을 때 마다 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스 제공에 이용(세션에 로그인이 되어있다고 저장을 해두고 서비스를 제공할때 그 데이터를 사용한다)

 

 

 

Stateless 서버 

상태를 유지하지 않는다. 서버는 클라이언트에서 들어오는 요청만으로 작업을 처리한다 

클라이언트와 서버의 연결고리가 없기 때문에 서버의 확장성이 높아진다.

server는 단순히 요청이 오면 응답을 보내는 역할만 수행하며 세션관리는 client에 책임이 있다.

client와의 세션정보를 기억 할 필요가 없으므로 정보를 서버에 저장하지 않는다.

확장성이 좋다 (어플리케이션으로도 확장 가능) 

 

 

JWT(Json Web Token)

 

jwt.io/

JWT.IO

JWT 인코딩및 디코딩을 해주는 사이트

 

JWT는

xxxxxxxxxx.yyyyyyyyyyy.zzzzzz 식으로 header, payload, signature 세 파트로 나뉘어져있다

 

header

type: 토큰의 타입

alg : 해싱 알고리즘 

주로 HMAC SHA256 혹은 RSA 가 사용이 된다. 

 

Payload

claim 정보를 포함하고있습니다.

등록된 클레임

서비스에서 필요한 정보들이 아닌 토큰에 대한 정보들이 담겨있다.

iss (토큰 발급자)

sub : 토큰 제목

aud : 토큰 대상자 

exp : 토큰의 만료시간 

nbf : not before 

iat : 토큰이 발급된 시간 

jti : jwt의 고유 식별자 

 

공개 클레임 

충돌이 방지된 이름을 가지고 있어야하며 클레임 이름을 URI 형식으로 짓는다

 

비공개 클레임 

클라이언트 < - > 서버간 사용하는 클레임이름이다. (id등)

 

Signature

헤더의 인코딩값과 정보의 인코딩값을 합친후 비밀키로 해쉬를 해서 생성을 한다.

 

 

 

 

인증 순서

1. 아이디와 패스워드로 인증 요청 

2. 서버는 인증을 수행 

3. 인증에 성공하면 signautre을 갖는 토큰을 클라이언트에 발급한다

4. 클라이언트는 토큰을 저장하고 서버 요청시 해당 토큰을 요청헤더에 담아 서버에 전달

5. 서버는 토큰을 검증한 후 요청에 응답한다

 

 

주로 두가지 토큰을 사용한다

1. API 요청을 허가하는데 사용하는 Access 토큰 (직접적으로 인증을 체크)

2. Access 토큰이 만료 된 후 새로운 액세스 토큰을 얻기 위해 Refresh Token을 사용한다 (클라리언트가 Access토큰이 없거나 만료되면 Refresh Token을 통해 Auth Server에 요청해서 발급을 받는다 ( 주로 만료기간이 길다, DB에 저장된다.)

 

 

 

Slding Sessions 전략 + AccessToken 

세션을 지속적으로 이용하는 유저에게 자동으로 만료기한을 늘려주는 방법 

유효한 AccessToken을 가진 클라이언트 요청에 대해 서버가 새로운 AccessToken을 발급해주는 방법

주로 유효한 AccessToken을 가진 요청에 대해 서버가 새로운 AccessToken을 발급해주는 방법 

장점

로그인을 자주 할 필요가없다

글을 작성하거나 결제를 하는등의 세션유지가 필요한 순간에 세션 만료 문제 방지 

단점

접속이 주로 단발성으로 이루어지는 서비스 경우 효과가 크지 않다. 

긴 만료시간을 갖는 AccessToken  -> 로그인을 전혀안해도 되는경우가 발생한다 

 

AccessToken + Refresh Token 

로그인 시 AccessToken과 함께 긴 만료시간을 갖는 RefreshToken을 클라이언트에 함께 발급한다

AccessToken(30분 내외) RefreshToken(2주~한달정도 만료)

AccessToken이 만료되었다는 오류를 받으면 따로 저장해두었던 RefreshToken을 이용하여 AccessToken의 재발급 요청 

서버는 유효한 refreshToken 요청이 들어오면 -> 새로운 AccessToken을 발급 -> 만료된 RefreshToken으로 요청이 들어오면 오류를 반환해 사용자에게 로그인을 요구한다.

RefreshToken의 경우 서버의 stroage에 따로 저장해서  이후 검증에 활용해야한다 (탈취가 되어서는 안된다)

 

장점

짧은 만료기간을 사용할 수 있기에 AccessToken이 탈취되더라도 제한된 기간만 접근 가능 

로그인을 자주 할 필요가없다 

RefreshToken에 대한 만료를 강제로 설정가능 

 

단점

클라이언트는 AccessTOken에 만료에 대한 연장 요청을 구현해야한다.

인증 만료기간의 자동연장이 불가능 하다 

서버에 별도의 storage를 만들어야한다. 

 

 

Sliding Sessions + AccessToken + RefreshToken

해당 방식은 RefreshToken의 만료기간을 늘려준다

빈번하게 만료기간을 연장 해줄 필요가 없다

장점

RefreshToken의 만료 기간에 대한 제약을 받지 않는다

글을 작성하거나 결제를 하는등 세션유지수간에 세션이 만료되는 문제를 방지 할 수 있다.

 

단점

서버에서 강제로 RefreshToken을 만료하지 않는 한 지속적으로 사용이 가능하다

인증이 추가되는 경우 보안 강화가 필요

 

 

 

 

 

 

 

 

 

 

참고 사이트 

blog.ull.im/engineering/2019/02/07/jwt-strategy.html 

swalloow.github.io/implement-jwt/

velopert.com/2389