로그인
로그인을 하는 이유?
: 매 요청마다 아이디와 비밀번호를 전송(쿼리, 아이디와 비밀번호 노출 횟수 증가)하지 않고 사용자 정보(접근권한) 유지
사용자가 입력한 비밀번호 암호화
아이디와 비밀번호 해시값 데이터베이스에서 탐색
세션 기반 인증
: 서버가 관리
발급
서버 쪽 저장소에 세션 생성(key: 세션ID - value: 사용자 정보)
세션ID를 클라이언트에게 응답
사용
클라이언트는 서버에 요청할 때마다 세션ID도 전송
서버는 세션 ID로 사용자 식별
삭제
로그아웃하면, 서버는 해당 세션 삭제
장점
서버 보안이 (클라이언트보다) 더 좋고 세션 관리가 가능
단점
사용자들이 동시에 많이 접속하면 서버 저장소에 부하
저장소에 문제가 생겨서 세션들이 전부 날아가면, 로그인한 사용자들은 전부 다시 로그인해야 함
여러 대의 서버들로 운영되는 경우 세션을 공용 저장소에 저장해야 함
토큰 기반 인증
: 클라이언트가 관리
발급
서버가 사용자 정보와 비밀 키를 이용하여 토큰을 발급하고 클라이언트에게 응답
클라이언트 단의 저장소(쿠키, 로컬 스토리지, 세션 스토리지)에 저장
사용
클라이언트는 요청을 보낼 때마다 해당 토큰을 서버에 전송
서버는 토큰으로 사용자 식별
삭제
로그아웃하면, 클라이언트 저장소에서 해당 토큰 삭제
장점
서버 쪽 저장소의 부하를 신경 쓸 필요 없음
단점
토큰 자체에 로그인한 사용자의 상태 정보가 담겨 있음
한 번 발급한 토큰을 유효기간 지나기 전까지 무효화시킬 방법이 없음
-> 해킹당했을 때 피해 더 큼
JWT(JSON Web Token)
토큰 기반 인증에서 사용하는 대표적인 토큰
헤더(Header)
페이로드(Payload)
서명(Signature)
각 부분을 Base64로 인코딩하고 이들을 마침표(.)를 이용하여 차례대로 연결
빨간색 부분이 헤더, 보라색 부분이 페이로드, 하늘색 부분이 서명
헤더 (Header)
토큰의 타입 ex) 'JWT'
서명 계산 및 토큰 검증에 사용할 암호화 알고리즘 ex) HS256(SHA256), RSA
페이로드 (Payload)
로그인한 사용자의 상태 정보 ex) 누가 누구에게 발급한 토큰인지, 유효 기한, 사용자에게 공개하고자 하는 정보들은 무엇인지 등
서명 (Signature)
: 토큰의 무결성, 유효성을 검증하는 데 사용
(헤더와 페이로드를 Base64로 인코딩하고, 이 둘을 마침표(.)로 연결한 것을 서버의 비밀 키와 함께 암호화 알고리즘에 넣어서 얻은 값)
서버는 받은 토큰의 헤더와 페이로드로 서명 값을 계산하고, 계산해서 얻은 값과 받은 토큰에 있는 서명 필드가 동일한지 검사(무결성)
만약 동일하지 않다면 요청을 거부하고, 동일하다면 유효 기한을 검사
단점
JWT의 페이로드를 Base64로 디코딩만 하면 해당 사용자의 정보를 손쉽게 얻어낼 수 있음
이미 발급된 JWT는 무효화를 하기가 어려움 -> 한 번 해킹당하면 유효기간 끝날 때까지 못 막음
리프레시 토큰
로그인에 성공하면, 두 개의 토큰을 발급
액세스 토큰: 사용자의 상태 정보 저장하는 토큰
리프레시 토큰: 액세스 토큰을 다시 발급받기 위해 서버에 전송하는 토큰
액세스 토큰의 유효 기간을 짧게 유지(해커가 오래 쓰지 못하도록)
로그인한 사용자의 상태 정보를 서버가 관리 가능
동시 로그인 관리 가능: 동일한 리프레시 토큰을 공유
토큰을 어디에 저장할까?
(session storage -> 브라우저 종료 시 초기화)
local storage -> 반영구적
cookie -> 브라우저에서 자동으로 보내는 값, 해커 코드 자동으로 실행되는 경우 : CSRF
db : refresh token에 대한 hash table
참고문헌
https://it-eldorado.tistory.com/164
https://it-eldorado.tistory.com/165
https://blog.lgcns.com/2687
https://programming-workspace.tistory.com/51
