[WIL][week1] 프로젝트 IMDb99 - 프로젝트 회고

G-NOTE·2022년 7월 17일

JWT 항해99

항해99

목록 보기

11/36

JWT

jwt는 예전에 로그인을 유지할 방법을 찾다가 블로그나 유튜브에서 개념만 보고 직접 사용해본 적은 없었다.
나중에 기회가 되면 사용해봐야지 했는데 이번 프로젝트를 진행하면서 간단하게나마 써볼 수 있어서 좋았다.

JWT란?

JWT(JSON Web Token)란, 인터넷 표준 인증 방식 중 하나로 인증에 필요한 정보들을 token에 담아 암호화 시켜 사용한다.

JWT 구성

JWT는 Header/Payload/Signature로 구성되어 있다.

Header : 토큰의 타입, 서명 생성할 때 어떤 알고리즘이 사용되었는지 저장

{
  "typ": "JWT",
  "alg": "HS512"
}

Payload : token의 property를 key-value 형태로 저장, 개발자가 원하는 정보를 넣는다. (payload에 값을 넣는 JWT의 표준 스펙이 있음)

{
  "id": user_receive,
  "exp": datetime.utcnow() + timedelta(seconds=60 * 60 * 24) 
}

Signature : 디코딩 된 header, payload 값을 합치고 서버가 가지고 있는 개인key로 암호화한다. 그 정보가 담긴 것이 signature 즉, 서명이다. signature 덕분에 클라이언트에서 악의적으로 토큰을 수정하더라도 서버는 전달받은 토큰이 인증된 토큰인지 구분할 수 있다.

JWT의 장점

가장 큰 장점은 서버에서 사용자가 로그인했는지 안 했는지 신경쓰지 않아도 되는 것이다. 사용자가 서버에 request를 보낼 때마다 토큰을 함께 보내기 때문에 서버는 해당 토큰이 유효한지 검사하고 request를 처리하면 되기 때문이다.
인증 관련 정보를 db에 저장해야 한다면 사용자가 늘어날 수록 db가 필요하고, 인증 할 때마다 db에서 확인해야 하므로 인증 서버 과부하가 올 수 있다. JWT는 request에 로그인 사용자 정보를 담아서 보내기 때문에 별도의 인증서버나 db에 대한 부담이 적다.

JWT의 단점

이번 프로젝트에서 겪은 문제는 없었지만 JWT를 사용할 때 단점이나 문제점은 무엇이 있을까 궁금해서 정리해봤다.

self-contained : 토큰 자체에 로그인 정보가 담겨있기 때문에 보안 측면에서 양날의 검이 될 수 있다. (저장할 수 있는 정보가 제한적)
토큰은 한 번 발급되면 만료될 때까지 폐기할 수 없다.
payload encoding : 페이로드 자체가 암호화된 것이 아니라 Base 64로 인코딩되어 있다. 따라서 중간에 페이로드를 탈취하여 디코딩하면 데이터를 볼 수 있다. JWE로 암호화하거나 페이로드에 중요한 데이터를 담지 않아야 한다.
- Base 64 : 8bit 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 코드 문자로 이루어진 문자열로 변경하는 인코딩 방식
- JWE(JSON Web Encryption, JSON 웹 암호화) : 서버와 클라이언트 간 전송되는 데이터를 암호화한 것 (페이로드는 입력하고 JWE object를 출력해서 생성한다.)

JWT 보안 전략

토큰의 만료 기간을 짧게 설정 : 토큰이 탈취되어도 만료 기간이 짧기 때문에 피해를 줄일 수 있으나 사용자가 자주 로그인해야 하는 단점이 있다.
sliding session : 클라이언트가 지속적으로 서비스를 이용하고 있는 경우 토큰 만료 기한을 늘려주는 방법으로 이 경우 사용자가 서비스를 이용 중일 경우 자주 로그인 할 필요가 없어진다.
Refresh Token : 클라이언트가 로그인 요청을 보낼 때 서버는 Access Token과 이보다 만료 기간이 긴 Refresh Token을 발급한다. 서버는 db에 저장된 Refresh Token과 비교하여 유효할 경우 Access Token을 발급하고, 만료된 경우 사용자는 재로그인해야 한다. 단, 이 경우 Refresh Token을 별도의 storage에 저장해야 하고 추가적인 I/O 작업이 발생하기 때문에 JWT의 장점을 누리기 어렵다.

REST API

REST API란 HTTP를 기반으로 클라이언트가 서버의 리소스에 접근한 방법을 규정한 아키텍처다.
HTTP URI를 통해 resource를 명시하고 HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
(HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용할 수 있다.)

REST API 구성

구성 요소	내용	표현 방법
자원(resource)	자원	URI(end point)
행위(verb)	자원에 대한 행위	HTTP 요청 메서드
표현(representation)	자원에 대한 행위의 구체적인 내용	payload

HTTP 요청 메서드 종류

HTTP 요청 메서드	종류	목적
GET	index/retrieve	모든/특정 리소스 획득
POST	create	리소스 생성
PUT	replace	리소스 전체 교체
PATCH	update	리소스 일부 수정
DELETE	delete	모든/특정 리소스 삭제

node.js 서버나 외부API에 요청을 보내는 용도로 사용해왔는데 이번 프로젝트를 진행하면서 간단하게나마 python을 사용할 수 있었다. 이때 DB의 사용자 정보를 컨트롤하기 위해 python에 REST API로 요청을 보내볼 수 있었다.

프로젝트 후기

Preview

느낀 점

초반에 JWT나 jinja 같은 생소한 개념도 함께 공부하며 프로젝트를 진행하다 보니 원리를 제대로 알고 쓰는게 아니라 코드 복붙만 하고 있는게 아닌가 싶었다. 늘 그랬듯 배운 코드를 가져다 쓰다보니 생각지 못한 에러나 문제상황을 겪게 되었고, 이런 문제를 해결하는 과정에서 직접 부딪쳐가며 원리나 실행 흐름을 파악할 수 있어서 좋았던 것 같다.
디자인 시안을 만들 시간이 없어서 reference 사이트였던 IMDb를 참고해서 css작업을 했는데 걱정했던 것보단 잘나온 것 같아 만족스러웠다.
그동안 React와 styled-components 사용에 익숙해져 있던 터라 JavaScript만 사용하면서 DOM 관리에 스트레스를 받다보니(데이터 업데이트될 때마다 리소스를 전부 가져오는 등..) 새삼 리액트의 소중함을 깨닫기도 했다. 게다가 props를 넘겨서 바로 스타일링에 적용할 수 있었던 styled-components와 달리 css는 그냥 경우에 따라 class를 다르게 주는 방식으로 해결해야 하다보니 많은 번거로움을 느끼기도 했다.