[WIL] w+1

river·2022년 3월 13일

JWT RESTfulAPI WIL hh99 항해99

항해99에 본격적으로 합류하게 된지 일주일이 지났다.
합류와 동시에 시작하게 된 미니 프로젝트로 4일이 순식간에 지나가버렸고, 알고리즘 열댓문제를 풀고나니 나머지 이틀도 어느새 지나온 뒤였다.

6일동안 작성한 TIL들을 다시 살펴보니 그동안 배우고 익힌 것들이 꽤나 많았다. 이래서 til,wil을 쓰는구나. 성장과정이 어느정도 보이니 괜히 뿌듯한 마음이 또 😝

[TIL] d+1

https://velog.io/@greeneryyyyy/TIL-d1
합류 첫 날. 미니프로젝트의 시작.
강의를 보며 로그인 기능을 구현하느라 하루를 보냈다.
불행히도 제대로 작동하도록 만들지는 못했다.

display:none; 설정이 담긴 class를 이용해 하나의 페이지에서 두가지 화면을 만들어 내는 것이 재미있었다.

[TIL] d+2

https://velog.io/@greeneryyyyy/TIL-d2

전날 로그인 기능이 작동하지 않았던 이유는 토큰을 쿠키에 담기 위해 코드를 짜놓고 정작 쿠키 플러그인을 import 하지 않았기 때문이었다(ㅋㅋㅋ) 코드를 삽입해 해결했다.
팀원분의 깃허브가 한참 동안 연동되지 않아 온 팀원들이 머리를 싸매고 고민했다. 덕분인지 브랜치를 다루는 방법에 대해 좀 더 잘 알게 되었달까...? ㅋㅋㅋㅋㅋ
저녁엔 팀별 면담에서 계획서에 대한 간단한 피드백을 들을 수 있었으며, 개인 면담에선 소소한 궁금증들에 대한 답을 들을 수 있었다.

로그인 기능은 어떤식으로 구현했냐는 질문에 제대로 답하지 못하고, 아마 쿠키 목록에서 확인이 가능하니 쿠키를 쓰는 방식이 아닐까? 하는 마음에 쿠키를 쓰는 것 같다고 어물어물 대답했는데, 멘토님께서 보통은 jwt를 쓰는 방식을 많이 사용한다며 좀 더 알아보는게 좋을 것 같다고 말씀해주셨다.

* 그렇다면 JWT가 뭘까?

JWT(Json Web Token)는 쿠키, 세션을 이용한 로그인 방식의 단점들(보안, 편의성 등...)을 보완하기 위해 만들어진 인증 방식이다.

쿠키를 사용한 방식의 경우, 쿠키가 노출되면 id와 pw 같은, 쿠키 속에 담긴 정보들이 한꺼번에 노출이 되는 문제가 있었고, 세션 방식의 경우 따로 인증 정보를 저장할 서버를 마련하고 관리해야 하는 단점이 있었으니, 이번엔 Token이라는 일종의 암호화된 신분증!을 만든 것이다.

사용자가 로그인을 시도하면 서버는 사용자가 입력한 정보를 검증하고, 토큰을 발급한다. 그리고 이를 클라이언트에 저장해두었다가 필요한 경우에만 서버와 주고받도록 만든 것이다. 서버는 굳이 매번 DB를 조회하지 않고 이 토큰이라는 신분증만을 확인하기 때문에 더욱 절약적이고 위험성도 적다.

물론 단점도 있다.
jwt는 쿠키/세션에 비해 저장 자원 면에선 절약적이나, 길이가 길기 때문에 인증 요청이 많아질수록 네트워크에 부하를 주기도 하고, 따로 세션 서버를 거치지 않기 때문에 토큰이 탈취되는 경우 토큰이 만료되기 전까진 대처할 수 없다. (토큰의 만료시간을 줄여 이를 보완할 수는 있지만, 사용자는 만료시간이 줄어든 만큼 다시 로그인을 해야 하는 불편함을 겪게 된다.)

- 또 그렇다면, 우리 프로젝트의 로그인 방식은 과연 뭐였을까?

결론적으로 우리 프로젝트에 사용된 것은 jwt를 이용하는 방식이 맞았다. 다만 토큰을 클라이언트에 저장해놓기 위해 쿠키를 그릇으로 활용한 것이고, 그래서 쿠키 목록에서 토큰을 확인해야 했던 것이다. (다행이다...!)

* RESTful API

REST(REpresentational State Transfer)

HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

이러한 REST 기반의 API를 웹으로 구현한 것을 RESTful API라고 한다. 쉽게 말하자면 그동안 프로젝트를 진행하며 파이썬을 이용해 서버를 만들었던 게 전부 RESTful API였던 것이다

REST의 특징으로는 일관된 인터페이스, 무상태성(세션정보나 쿠키정보를 활용해 상태정보를 저장하지 않음), 캐시 가능, 서버-클라이언트 구조, 자체 표현, 계층 구조 등이 있다.

RESTful API의 구성요소

Resource : 서버는 Uniquegks ID를 가지는 리소스를 가지고 있으며, 이러한 리소스에 요청을 보낸다. 이러한 리소스는 URI*에 해당한다.
Method : 서버에 요청을 보내기 위한 방식. (ex_GET, POST...) CRUD 연산 중에서 처리를 위한 연산에 맞는 Method를 사용해 서버에 요청을 보내야 한다.
Representation of Resource : 클라이언트와 서버가 데이터를 주고 받는 형태. json, xml, text, rss 등이 있다. 최근에는 json을 주로 사용한다.