정신없이 지내다 보니 벌써 일주일이 지났다니..
미니 프로젝트가 끝난 후 마음의 여유가 생긴건 좋지만 뭔지 모를 공허함이 남아있다. 주특기 강의를 받기 전까지 혼자 공부하는 시간을 가지려고 하니 제한된 시간 안에 결과물을 만들어야 하는 팀 프로젝트 때와 달리 긴장감도 없고 느슨해진 기분이 든다. 분명 프로젝트 할 때는 잠도 제대로 못자고 힘들다고 생각했는데 그 시간이 오히려 내가 더 살아 있음을 느낀다.
일단 오늘은 이번주에 알게 된 것들을 한번 정리 해보려고 한다.
JWT
처음엔 그저 로그인 창을 만들고 회원가입 창을 만들고 메인 페이지를 만드며 잊고 있었지만 어느정도 완성이 된 후에 JWT방식을 사용하지 않는 다는 것을 인지하고 Server의 코드를 수정 하려 했다. JWT를 제외하고 이미 완성 되어있는 코드에 JWT 기능만 추가하면 되는 간단한 수정이였지만 어디서 잘못 된건지 찾지도 못하고 이틀을 고민 하다 결국 서버 코딩을 처음부터 다시 진행 하였다.
처음부터 JWT를 구현 하고나서 그 위에 기존 작업했던 코드를 올리니 동작이 되긴 했지만 정확히 어디 부분이 문제여서 구현을 못했던 것인지는 아직 찾지 못했다.
API
이번 프로젝트 메인페이지의 핵심 기능인데
"필요 조건을 선택한다. -> ENTER 버튼을 누른다. -> 원하는 조건의 닉네임이 생성된다."
위 기능을 구현 하기 위해 내가 작성한 코드의 동작 방식은 웹사이트를 크롤링 하여 API를 만든 후
"ENTER 버튼 클릭 시 동작 한다. -> API에서 받아온 데이터를 다시 리스트로 만든다. -> 필요한 조건에 따라 리스트에서 가져온다." 라는 동작을 수행하여 원하는 단어를 뽑아준다. 지금도 확실 하지는 않지만 "API에서 받아온 데이터를 다시 리스트로 만든다."의 과정은 API를 만들 때 부터 분류를 제대로 나눴으면 필요 없는 과정이지 않았을까 하는 생각이 든다.
JWT, API는 뭘까? 라는 질문을 생각을 해보았다..
당장 대답할 수 있던 것은 "JSON Web Token의 약자이고 사용자 인증을 토큰으로 저장하여 사용한다.", "API는 서버쪽 에서 Data를 받아오기 위한 창구?.." 라고 하는게 끝이였다.
이번 프로젝트를 진행 하며 분명히 사용 했던 기능이고 구현도 잘 안되서 애를 먹으며 한참을 찾아 보았던건 맞지만 어떻게 해야 기능이 동작하는지에 대해서만 고민했지 JWT, API는 무슨 원리로 동작을 하며 왜 사용하는지에 대해 찾아보지는 않았기에 다시 찾아본 자료를 바탕으로 그저 보고 그대로 작성 한거지만 직접 타이핑 하며 한 글자라도 더 머릿속에 넣으려고 노력했다.
JWT 란
- JSON Web Token의 약자로 전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON이다.
- JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준 이다.
- JWT는 서버와 클라이언트 간 정보를 주고 받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증한다.
- 이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 만든다.
JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있다.
JWT 토큰 구성
JWT는 세 파트로 나누어지며, 각 파트는 점으로 구분하여 xxxxx.yyyyy.zzzzz 이런식으로 표현된다. 순서대로 헤더 (Header), 페이로드 (Payload), 서명 (Sinature)로 구성한다.
Base64 인코딩의 경우 “+”, “/”, “=”이 포함되지만 JWT는 URI에서 파라미터로 사용할 수 있도록 URL-Safe 한 Base64url 인코딩을 사용한다.
Header
토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있다. 첫째는 토큰의 유형 (JWT)을 나타내고, 두 번째는 HMAC, SHA256 또는 RSA와 같은 해시 알고리즘을 나타내는 부분이다.Payload
토큰에 담을 클레임(claim) 정보를 포함하고 있다. Payload 에 담는 정보의 한 ‘조각’ 을 클레임이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임 들을 넣을 수 있다.
클레임의 정보는 등록된 (registered) 클레임, 공개 (public) 클레임, 비공개 (private) 클레임으로 세 종류가 있다.Signature
secret key를 포함하여 암호화되어 있다.
JWT Process
일반적으로 JWT 토큰 기반의 인증 시스템은 위와 같은 프로세스로 이루어진다.
처음 사용자를 등록할 때 Access token과 Refresh token이 모두 발급되어야 한다.
JWT의 장,단점
JWT의 장점
- JWT 의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없음
- 디버깅 및 관리가 용이
- 트래픽 대한 부담이 낮음
JWT의 단점
- 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없음
- 더 많은 필드가 추가되면 토큰이 커질 수 있음
- 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있음
API 란
애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces, API)는 애플리케이션 소프트웨어 및 서비스를 통합하는 툴, 정의, 프로토콜의 세트이다. 이는 새로운 연결 인프라를 지속적으로 구축할 필요 없이 제품 및 서비스가 서로 커뮤니케이션할 수 있도록 도와주는 기능이다.
- API는 흔히 function, method 또는 operation 등으로 다양하게 불리는 '소프트웨어 컴포넌트'의 기능, 입력, 출력, 그리고 이에 사용되는 자료형으로 표현된다. API 자체는 어디까지나 사양(specification)만을 정의하기 때문에 구현(Implementation)과는 독립적이다. 앞서 언급했다시피 이를 실제로 구현한 것은 '라이브러리(library)'라고 부른다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해준다. API는 다양한 형태로 존재하며, 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, C++의 표준 템플릿 라이브러리 (STL), Java SE API 등이 이에 해당한다.
- API는 통합이 핵심이다. 이는 데이터, 애플리케이션 및 기기를 IT 조직 전반에서 연결하여 기술 전체가 서로 원활히 통신하고 잘 연동되도록 해준다. 기술이 제대로 연동되지 않거나 통신이 이루어지지 않으면 시간과 비용을 낭비하게 된다.
