토큰 기반 인증 시스템
- Stateless서버
- 상태를 유지하지 않고, 서버는 클라이언트 측에서 들어오는 요청만 작업,
이렇게 하면 클라이언트와 서버의 연결고리가 없기 때문에
확장성
이 높아진다.
- 상태를 유지하지 않고, 서버는 클라이언트 측에서 들어오는 요청만 작업,
이렇게 하면 클라이언트와 서버의 연결고리가 없기 때문에
서버 기반 인증
문제점
- 세션
- 유저가 인증을 할 때, 서버에 상태를 저장해야한다. (세션)
- 유저의 수가 늘어나면 과부하!
- 확장성
- 세션 사용시 서버 확장성이 어려워진다. (분산 시스템 설계 매우 복잡)
토큰 기반 시스템
- 유저 인증 정보를 서버나, 세션에 담지 않는다.
작동 원리
- 유저 로그인
- 서버에서 로그인 검증
- 로그인 정보가 일치하면, 서버에서 유저에게 토큰 발급
- 클라이언트에서 발급받은 토큰을 저장하고, 서버에 요청을 보낼 때마다 토큰을 함께 전달한다.
- 서버에서는 함께 온 토큰을 검증하고, 요청에 응답한다.
OAuth 토큰 동작 과정
- 클라이언트가 서버(토큰발급서버)로 토큰을 요청
- 서버는 사용자 계정 확인후, 토큰 발급
- 발급 후,
DB
에 해당 토큰 정보 저장(토큰, 사용자 정보, 권한 등...) - 해당 토큰정보 db의 접근 할 수 있는 토큰을 클라이언트로 보낸다.
- 클라이언트는 이 토큰을 가지고 리소스 서버에 요청을 보낸다.
- 서버에서는 받은 토큰을
DB
에서 권한 정보를 찾아서 요청을 수행한다.
JWT 토큰 동작 과정
- 클라이언트가 서버로 토큰 요청
- 서버에서는 생성된 토큰을 따로
DB에 저장하지 않고
토큰에 연관되는 사용자 정보나 권한 등을 토큰 자체에 넣어서 저장한다. - 그리고 이렇게 만들어진 토큰을 클라이언트에 저장한다.
- 클라이언트가 리소스를 서버로 요청할때, 서버는 해당 토큰에 있는 사용자 정보와 권한 정보를 가지고 요청을 처리한다.
OAuth, JWT 차이점
- JWT는 토큰에 대한 정보를 별도로 서버에 유지할 필요가 없다. 따라서 DB에서 조회를 하는 과정이 필요없다. (사용자가 가지고온 토큰에 이미 사용자 정보랑, 권한이 있기 때문이다.)
JWT
JWT는 Claim을 JSON형태로 표현한다.
그러나 JSON은 개행 문자가 있기때문에 HTTP Header에 넣기 불편하다. 그래서 JWT에서는 이 Claim JSON문자열을 BASE64 인코딩을 통해서 하나의 문자열로 변환
JWT 구조
- JOSE Header
- JWT Claim Set
- Signature
JOSE (Json Object signing and Encryption) Header
- JWT토큰을 어떻게 해석해야 하는지 명시한다.
- HMAC방식
- 원본 메시지에서 해쉬값을 추출한 수, 이를 비밀키를 이용해서 복호화 시켜서 토큰 뒤에 붙이는 방식
- 비밀키를 모르는 이상 HMAC를 만들어 낼수 없어서 변조가 불가능하다.
JWT Claim Set
- 실제 토큰 정보(사용자 정보, 권한 정보 등)
Signature
- JOSE Header와 JWT Claim Set가 위변조 되어있는지 검증하기 위한 부분
전체 메시지 구조
{서명 방식을 정의한 JSON을 BASE64 인코딩}.{JSON Claim을 BASE64 인코딩}.{JSON Claim에 대한 서명}
참고 사이트
'WEB' 카테고리의 다른 글
[JSP] 서블릿 동작구조 & 생명주기 / JSP 동작구조 (0) | 2018.07.09 |
---|---|
[JSP] Servlet과 JSP (0) | 2018.07.09 |