항해99 1주차 회고록 및 개념 정리(JWT, API)

1. 첫 번째 미니 프로젝트

항해99를 처음 시작하고 첫째 날부터 처음 보는 사람들과 미니 프로젝트를 진행하였다. 항해99에 들어오기 전에는 누군가와 팀을 이루어 협업해본 경험도 없고 혼자서 스프링 부트를 통해 간단한 CRUD 게시판을 만들어 본 것이 전부인 제 자신에게 있어서 누군가와 프로젝트를 진행하는 것에 대한 즐거움을 알 수 있게 해주는 시간이었던 것 같다.

• 마주쳤던 문제점
  • HTML 및 DB에 데이터 저장하는 방법 개선
    이전 글에서 설명하였 듯이 저희 조는 스케줄을 관리할 수 있는 페이지(일종의 todo list)를 만들기로 하였고 날짜도 같이 데이터베이스에 넘겨주기 위해 select와 option 태그를 사용하여 '년', '월', '일'을 따로 받아 DB에 넘겨주었었다. 이후 기술 매니저님과의 멘토링을 통해 날짜 순서대로 스케줄을 정렬하기 원했던 저희 입장에서 한번에 DB로 넘겨주는 것이 어떻냐 하셨고 해당 멘토링을 통해 <input type="date">를 통해 달력을 만들어 한번에 DB에 값을 보내도록 수정하였다. 다시와서 생각해보니 DB에 데이터를 넘길때 뿐만 아니라 사용자들이 데이터를 입력할 때도 년, 월, 일 세 개의 옵션을 클릭하는 것 보다 달력을 찾아 한 번 클릭하는 것이 훨씬 편할 것 같다는 생각이 들었다!
    
    

    날짜를 받기 위한 기존 와이어프레임

    
    
    

    수정 후

    

  • 로그인 기능
    JWT를 사용하여 토큰을 쿠키에 저장하는 것 까지는 성공하였지만 로그아웃을 구현하지 못하고 프로젝트를 제출한게 정말 너무 아쉬웠다. 또한 회원가입과 로그인 기능은 구현하였지만 로그인 없이 메인 페이지를 단순히 url을 입력하여 들어갈 수 있는 점도 아쉬운 부분 중 하나이다. 프로젝트 제출 기간은 끝났지만 따로 공부하여 마저 제 기능을 다 할 수 있도록 구현할 예정이다.
    
    
    
    

2. 1주차 배운 개념 정리

JWT(JSON Web Token)

JWT는 인가(Authorization, 인증을 받은 사용자가 이후 서비스를 사용할 때 이를 허가)와 관련된 기술이다.

토큰은 인코딩 또는 암호화 된 3가지 데이터(Header, Payload, Verify Signature)를 이어붙인 형식으로 구성되어 있고 .으로 각각 구분된다.

- 토큰 예시

출처 : https://jwt.io/

• Header에는 토큰의 type과 Verify Signature를 만드는데 사용될 알고리즘이 지정된 alg이 지정된다. Header와 Payload 그리고 비밀 키를 통해 Verify Signature 값을 만들 수 있다. Verify Signature과 계산 값이 일치하고 유효기간이 지나지 않았다면 해당 사용자는 로그인된 회원으로서 인가를 받을 수 있다. 따라서 서버는 사용자의 상태를 모르고(stateless) 비밀 키를 통해 사용자에게 인가를 해줄 수 있다.

• Payload를 디코딩해보면 JSON 형식으로 이 토큰이 언제까지 유효한지, 서비스가 사용자에게 이 토큰을 통해 공개하길 원하는 내용 등 여러 정보들이 들어있다. 이렇게 토큰에 담긴 사용자 정보 등의 데이터를 Claim이라고 한다.

• 위 글에서 언급하였 듯이 JWT는 stateless하여 생기는 단점도 있다. stateful한 세션처럼 모든 사용자의 상태를 기억하고 있는건 구현도 부담되고 고려사항이 많지만 기억하는 대상의 상태들은 언제든 제어할 수 있다. 이와 다르게 JWT에서는 사용자의 상태를 기억하고 있지 않기 때문에 통제를 하기 힘들다는 결점이 있다. 하지만 이런 점을 대응하기 위해 로그인을 하면 토큰의 수명이 짧은 Access Token과 이에 비해 기간이 긴 Refresh Token을 같이 발급하여 Refresh 토큰은 DB에 저장을 한다. 이후 Access Token에 수명을 다하면 Refresh Token을 보내 서버는 이를 DB에 Refresh Token 값과 비교를 하여 새로운 Access Token을 발급해주는 방법이 있다. 서버는 Refresh Token을 통해 Access Token을 제어하여 어느 정도 통제를 할 수 있게한다.
  
  
  
  

API(Application Programming Interface)

API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.
...
API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.

출처 : https://aws.amazon.com/ko/what-is/api/ (AWS)

즉 API란 프로그램(코드)들이 서로 소통하는(데이터를 주고받는) 방법이다.

Ex) 웹툰서비스 API

웹툰서비스 API는 웹툰 서버와 손님이 웹툰을 주고받기 위한 방법이다.

위 정의에서 언급하였 듯이 API는 코드들이 서로 소통하는 방법이기 때문에 사용자가 웹툰을 보기 위해서는 코드들을 작성해야 한다. ( 참교육 웹툰을 보기위한 GET 요청, comic.naver.com/webtoon/list?titleId=758037&weekday=mon )

하지만 실제 사용자들은 직접 코드를 작성하지 않는다. 브라우저를 통해 웹툰 이미지, 제목을 누르면 자동으로 그에 해당하는 API를 요청하게 할 수 있도록 한다(웹툰 페이지에서 참교육 제목 또는 이미지를 클릭).

• API의 역할
  
  
  • 애플리케이션과 기기의 소통 창구 : API는 우리가 앱을 사용하면서 버튼을 누르거나 검색어를 입력하는 등 정보를 얻기 위한 행동을 했을 대 이를 서버가 알아들을 수 있는 요청 값으로 전달하는 역할을 한다.
    
    
  • 서버와 데이터베이스의 문지기 : 앱에 사용되는 모든 데이터는 서버에 저장되어 있다. 따라서 원하는 정보는 서버를 통해 받아와야 하는데 API는 허용된 사용자에게만 특정 키값을 부여하고 데이터에 접근할 수 있도록 권한을 주는 문지기 역할을 수행한다.
    
    
  • 모든 접속을 표준화 : 각기 다른 기기나 운영체제에서 접근하더라도 누구나 동일한 결과를 얻을 수 있도록 접속을 표준화 하는 역할을 수행한다.

REST(Representational State Transfer) API

HTTP 프로토콜을 통해 API를 설계하기 위한 아키텍처 스타일로 정보들을 주고 받는데 있어서 개발자들이 널리 쓰이는 형식이다.

RESTful API

RESTFUL이란 REST의 원리를 따르는 시스템을 의미한다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있다.