JWT
JWT는 Json Web Token의 약자, 인증에 필요한 정보들을 암호화시킨 토큰
JWT 토큰을 HTTP 헤더에 실어 서버로 보낸다.
암호화된 토큰보기 https://jwt.io
토큰을 만들기 위한 3가지
Header : 정보를 암호화할 방식(alg), 타입(type)
Payload : 서버에서 보낼 데이터. 일반적으로 유저의 고유 ID값, 유효기간이 들어간다.
Verify Signature : Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.
Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화되지는 않는다. Header, Payload는 누구나 디코딩하여 확인할 수 있음.
Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없음.
JWT와 세션/쿠키
공통점
클라이언트에서 HTTP 헤더에 세션ID나 토큰을 실어서 서버에 보내준다.
차이점
세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 넣는다. JWT 방식은 인증을 위해 서버 측에서 정보를 암호화를 하고, 세션/쿠키 방식은 서버 측에서 별도의 저장소를 이용하는 차이가 발생
JWT 장점
세션/쿠키는 별도의 저장소의 관리가 필요하다. 그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요없다. 저장소에 상태를 저장하지 않아 서버를 확장하거나 유지,보수하는데 유리하다.
토큰 기반으로 하는 다른 인증 시스템에 접근이 가능. 예를 들어 Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증을 해서 확장성이 뛰어남.
JWT 단점
이미 발급된 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다. (세션/쿠키의 경우 쿠키가 악의적으로 이용되면, 해당하는 세션을 지우면 된다.)
Payload는 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있어 중요한 정보들은 Payload에 넣을 수 없습니다.(세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 보관된다.)
세션/쿠키 방식에 비해 JWT의 길이가 길어 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생한다.
API
API는 해당 프로그램의 기능을 다른 프로그램이 쓸 수 있게 하는 것이 목적. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
Ajax로 서버 API(약속)에 데이터를 주고, 결과를 받아온다.
서버 -> 클라이언트 전달 자료 형태 포맷: JSON
JSON은 {Key:Value} 형태의 딕셔너리 형태로 이루어져 있음.
클라이언트 -> 서버 요청 자료 타입 : GET / POST
GET
일반적으로 데이터 조회 요철할 때(영화 목록 조회)
데이터 전달 : URL 뒤에 물음표를 붙여 key=value로 전달
예: google.com?q=북극곰
https://movie.naver.com/movie/bi/mi/basic.nhn?code=161967
? 기준으로
서버주소 : https://movie.naver.com/movie/bi/mi/basic.nhn
영화정보 : code=161967
code 이름으로 영화정보를 주는 것은 프론트엔드 개발자와 백엔드 개발자가 미리 정한 약속이다.
POST
일반적으로 데이터 생성, 변경, 삭제 요청할 때(회원가입, 회원탈퇴, 비밀번호 수정)
데이터 전달 : 바로 보이지 않는 HTML body에 key:value 형태로 전달
쿠키, 세션, 캐시
1 .쿠키
쿠키는 사용자의 접속 인증(Authorization) 기록을 위한 기록증.
클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일.
사용자 인증이 유효한 시간을 명시할 수 있고, 유효 시간 안에 브라우저가 종료되어도 인증이 유지된다.
쿠키는 클라이언트 상태 정보를 로컬에 저장했다 참조한다.
쿠키의 구성요소
- 이름: 각각의 쿠키를 구별하는 데 사용되는 이름
- 값: 쿠키의 이름과 관련된 값
- 유효시간: 쿠키의 유지시간
- 도메인: 쿠키를 전송할 도메인
- 경로: 쿠키를 전송할 요청 경로
쿠키 동작방식
- 클라이언트가 페이지 요청
- 서버에서 쿠키 생성
- HTTP 헤어데 쿠키를 포함시켜 응답
- 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에 보관
- 같은 요청을 할 경우 HTTP헤더에 쿠키를 함께 보냄
- 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답.
2. 세션
세션은 쿠키랑 하는 일이 같다고 볼 수 있다. 그러나 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버측에 저장한다.
서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하여 웹브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.(브라우저가 종료되면 소멸)
접속시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능.
쿠키는 개인PC에서, 세션은 서버에서 처리하기 때문에 세션이 비교적 보안이 강하지만 사용자가 많아질수록 서버 메모리를 많이 차지한다.
세션 동작방식
- 클라이언트가 서버에 처음으로 Request 보냄
- 서버에서는 session id 쿠키 값이 없는 것을 확인하고 새로 발급해서 응답
- 클라이언트는 전달받은 session id 값을 매 요청마다 헤더 쿠키에 넣어 요청
- 서버는 session id를 확인하여 사용자 식별
- 클라이언트가 로그인을 요청하면 서버는 session을 로그인한 사용자 정보로 갱신, 새로운 session id를 발급하여 응답.
- 이후 클라이언트는 로그인 사용자의 session id 쿠키를 청과 함께 전달, 서버에서도 로그인된 사용자로 식별 가능
- 브라우저 종료 시 session id 제거, 서버에서도 세션 제거
세션의 특징
- 세션 아이디는 브라우저 단위로 저장되고 브라우저 종료시 소멸
- 로그인한 사용자에 대해서만 세션을 생성하는 것은 아니다. 로그아웃 하면 새로운 사용자로 인식해서 새로운 세션이 생성.
- 닉네임 등의 사용자가 요청 할 때마다 필요한 정보들을 세션에 담아두면 사용자 데이터베이스에 접근할 필요가 없어 효율적
3. 캐시
캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소
이미지 같은 재사용될 것 같거나 용량이 큰 리소스를 임시로 저장해두어 렌더링 속도를 높이는 것이 목적이다.
캐시는 사용자가 직접 수동으로 삭제해주어햐 한다.(쿠키는 만료기간이 지나면 자동 삭제된다.)
1주차 후기
항해99 3기를 함께 시작한 사람들은 다들 열정이 넘치고 의지가 대단해 보였다. 1주차 안에서도 출석체크 명단에 있던 이름들이 없어지는 경우도 있었지만 나는 끝까지 남아서 항해를 마무리 할 것이다. 물론 힘든 여정이 되겠지만 힘든만큼 남는 것도 많을 것이라고 생각한다. 다들 노력하는 모습을 보면서 나도 함께 노력하면서 나아가야 겠다.
