2022년 11월 8일 화요일
@ 하루를 빠지고 진행하는 날이어서 그런지,
파이널 프로젝트가 정해지고 나서 그런지,
집중이 안되는 상황이다, 그래도 하나라도 더
수업 내용을 넣으려고 하자.
[수업 순서]
- JWT
[Session 로그인]
- 세션은 고유 ID, 로그인 시간 및 만료 시간 등과
같은 사용자 정보를 저장하는 작은 파일이다.
사용자 요청을 추적할 수 있도록 서버에서 생성되어
서버에 저장된다. 사용자는 서버가 ID를 인식하고
사용자의 요청을 승인할 수 있도록 ID를 쿠키로 받고 이후
요청에 함께 보낸다. - 장점 : 구현이 간편하며 관리자가 세션에 대한
권한을 가지므로 즉시 세션 무효화도 가능하다. - 단점 : 세션이 서버의 메모리에 저장되므로 확장 시
어려움이 있다. - Sticky Session : 특정 세션 요청을 처음 처리한
서버로만 전송
(특정 서버만 과부화 될 수 있으며 특정 서버 장애 시
문제 발생) - Session Clustering : 여러 서버의 세션을 묶어
하나의 시스템처럼 동작하게 함
(동기화 과정으로 성능 저하) - Session Storage : 별도의 세션 저장소 사용
[Token 로그인]
- 토큰은 변조할 수 없는 권한 부여 파일이다.
서버에서 비밀 키를 사용하여 생성하고 사용자에게 보내
로컬 저장소에 저장한다. 쿠키의 경우와 마찬가지로
사용자는 새 요청이 있을 때마다 이 토큰을 서버에 전송하여
서버가 서명을 확인하고 요청을 승인할 수 있도록 한다. - 장점 : 클라이언트 측에 저장 되기 때문에 서버의 확장성에
문제가 없다. - 단점 : 클라이언트 측에 저장 된 내용이 탈취 되었을 때
보안상의 문제가 있다.
(민감한 데이터를 저장하지 않는다.)
(access token의 유효 시간을 짧게 잡는다.)
(refresh token을 별도로 활용하여
잦은 로그인 만료를 막는다.)
[JWT(Json Web Token)란?]
- 인증된 사용자를 식별하는 데 가장 일반적으로
사용되는 방식으로 인증 서버에서 토큰을 발급하고
이 토큰을 클라이언트-서버 통신에서 API 보안을 위해
사용한다. 이 토큰에는 공유해야 하는 정보가 있는
JSON 개체가 포함되어 있다. 또한 각 JWT는 클라이언트나
악의적인 당사자가 JSON 콘텐츠를 변경할 수 없도록
암호화(해싱)를 사용하여 서명된다.
[JSON Web Token의 구조]
- Header : 사용중인 서명 알고리즘과 토큰 유형
- Payload : Claim - 사용자 및 추가 데이터에 대한 설명
(iss(발급자), exp(만료시간), sub(제목) 등이
정의 된 클레임. 그 외에도 자유롭게 정의 가능.) - Signature : JSON Payload의 무결성 확인에
사용할 수 있는 암호화 알고리즘을 통해 생성 된 문자열
※ 확실히 어렵게 느껴진다, 곧 수료이고, 곧 취업인데
모든 것을 내 것으로 만들고 싶은 욕심이 있지만
실상은 그렇지 못하니, 스스로 자책하게 된다.
선택과 집중을 해야할 시기가 다가오고 있다는 것을
잊지 말고, 자존감을 높여야겠다는 생각이 든다!
야구선수 출신 개발자