WIL 1
JWT - JSON Web Tokens
JWT를 알아보며 느낀점
세션기반인증 VS 토큰기반인증
인터넷 표준인 만큼 로그인 기능을 만드는데 있어 교과적으로 따라야 하는 방식이라는 생각이 든다
2010년에 처음 생기고 2015년에 마지막 버전이 나온지 6년이 지난 지금 시점 딱히 대체재가 없는 안정화된 방식이라 생각이 든다. 그러다 보니 인터넷 표준이 되었고 로그인 기능과 기타 인증을 하는 방식에 있어 교과서 적인 방법이 되는것 같다. 깃허브도 인증방식을 기존에 아이디와 패스워드로 하던 방식에서 웹 토큰만을 지원하는 방식으로 변경된 만큼 웹 내에서 인증 및 정보교류를 하는 기능을 구현할 때 자주 써봐야 겠다.
아래 부터는 여기저기서 알아본 JWT를 내가 보기 편하게 작성한 내용이다.
출처
http://www.opennaru.com/opennaru-blog/jwt-json-web-token/
https://meetup.toast.com/posts/239
JWT는
1. 클라이언트와 서버
2. 서비스와 서비스
통신 시 권한인가(Authorization)를 위해 사용하는 토큰.
(URL에 대해) 안전한 문자열로 구성되어
HTTP(URL, Header) 어디든 위치가 가능하다.
토큰구성
header.payload.signature
- 해더
JWT를 어떻게 검증하는가에 대한 내용을 담고 있다.
=> Base64 URL-Safe 가 뭔지 알아야 함
- 페이로드
JWT의 내용.
페이로드에 있는 속성들을 클레임 셋이라 부름
클레임 셋이란?
서버에서 실질적으로 보낸 데이터, 토큰의 만료기간과 주인 등이 저장되어 있음.
- 서명
헤더와 페이로드를 합친 문자열을 서명한 값
활용 시나리오
- 회원인증
1. [사용자]가 로그인 시
2. [서버]는 사용자 정보기반 토큰 발급
3. [사용자]가 서버에 요청할 때 마다 JWT를 포함하여 전달
4. [서버]는 사용자에게 요청을 받을때 마다, 해당 토큰이 유효하고 인증 됐는지 검증하고, 사용자가 요청한 작업에 권한이 있는지 확인 하여 작업 처리
5. [서버]는 사용자에 대한 세션을 유지하지 않음
6. [사용자]가 로그인이 되었는지 아닌지 알 필요가 없음
7. [사용자]가 요청시에만 토큰을 확인하게 되어 세션관리가 필요없고, 서버자원과 비용절감에 효과적임
- 정보교류
1. 두 개체 사이에서 안정성 있게 정보를 교환하기 좋은 방법
2. 정보가 서명되어 있기 때문에 보낸이가 바뀌거나 정보가 조작되었는지 검증이 가능
API
프로그램을 작성하기 위한 서브 프로그램,
프로토콜등을 정의하여 상호작용하기위한 인터페이스 사양.
라이브러리와 비슷해 보이나 엄밀히 다른 개념
[API]가 CS분야의 추상적 개념이라면,
[라이브러리]는 API를 기반으로 개발자에게 기능을 제공할 수 있는 실제 구현된 구현체.
핵심은 정의된 프로토콜을 기반으로 상호 작용을 할 수 있도록 일종의 약속된 시스템
1주차 프로젝트를 하며 느낀점
로그인과 db부분을 맡지 않다보니 프로젝트 참여도가 높지 않았던것 같다
해당 부분 맡아주신 하나님과 희경님의 노고가 아주 많을것 같아 죄송한 마음이 있다
이 부분은 개인공부를 통하여 앞으로 프로젝트를 하는데 부족함 없도록 해야 할것 같다
git에 시간을 많이 쓰게 되었다.
덕분에 명령어와 기본적인 깃을 사용하는 순서는 손에 익었으나
팀원들과 함께 사용하는것은 아직도 미흡하다
기본적인 명령어 말고도 협업을 위한 명령어들의 사용법을 익혀야겠다
쓰다보니 프로젝트의 내용적 측면보다 팀에 대한 내용만 남게 되었다
다음주차는 프로젝트를 통해 배운것들을 잘 적용 할수 있도록 해야겠다