Serverless - JWT

> 로그인이 필요한 경우?

 

 

> Serverless 환경에서의 세션 관리

모든 람다마다 DB 커넥션을 가지고 데이터를 가져오는 것이 오버헤드가 될 수도 있다. 

 

그래서 사람들이 고민하기 시작했다. 

세션 정보 혹은 state 정보를 클라이언트가 보관하게 할 순 없을까? 라고 생각했다.

그럼 클라이언트가 그걸 보관하고 있다가 요청해서 주기만 하면, 람다는 그거대로 처리만 하면 되니까. 

외부 스토리지 도움 없이 자체적으로 하나의 로직을 처리할 수 있게 된다. 

그럼 문제가 뭘까?

클라이언트는 항상 변조가 가능하다. 내가 유저 등급 1인데, 10으로 바꿨어. 그럼 람다 입장에서는 그걸 그대로 믿는다.

그래서 클라이언트가 그 정보를 보관한다면 그걸 검증할 수 있는 로직이 필요하다. 

그 방법 중의 하나가 바로 jwt이다. 

 

 

> JSON Web Token

- RFC 7519 표준으로 JSON 포맷 기반으로 사용자에 대한 정보를 저장하는 Claim 기반의 토큰 

- Claim 기반 

    - 토큰에 대상의 정보를 담은 방식 

    - 장점

        - 토큰자체에 데이터를 저장하기 때문에 별도의 저장과정이 필요없음 

        - 자체적인 만료시간 구현 가능 (필수)

    - 단점

        - 토큰 자체의 제어 불가능 (취소 불가능)

        - 토큰에 정보를 담고 있어 탈취 당하였을 경우 정보가 공개됨 

- AWS의 API Gateway 등의 서비스에서 지원 

 

 

> JWT의 구성

- Header : 토큰의 타입과 알고리즘 종류

- Payload : 실제 데이터가 저장되는 공간 

    - iss : 토큰 발급자 (Issuer)

    - sub : 토큰 제목 (Subject)

    - exp : 토큰 만료시간 (Expiration)

    - iat : 토큰의 발급 시간 (Issued At)

- Signature

    - Header와 Payload의 정보를 검증하기 위한 고유한 암호화 스트링

    - 시그니처를 활용하여 jwt 토큰이 변조되었는 지를 판단할 수 있다. 

 

 

> JWT 인증 로직 

header와 payload를 비밀키로 서명을 만들고, 이를 signature로 jwt 토큰 뒤에 붙인다. 

이렇게 변조여부 판단이 가능하다. 

 

jwt 토큰은 다음과 같이 생겼다. 

 

그래서, 클라이언트는 이 jwt 토큰과 함께 서버에 API 요청을 보낸다. 

서버에서는 비밀 키로 토큰을 검증하고, 검증을 통과하면 토큰 내 정보들을 가져와 이런저런 처리를 한다. 

 

 

 

> Demo - JWT Token

- JWT Token을 생성하는 Lambda 함수 생성

- JWT Token 생성

- JWT Token 정보를 확인하는 Lambda 함수로 JWT 토큰 확인 

 

실습파일 준비

serverless.yml

serverless 프레임워크로 배포한다.

 

그럼 다음과 같이 엔드포인트를 리턴해준다.