공hannah부
인증 방식의 종류 & JWT 본문
인증 방식의 종류
Cookie
- Key-Value 형식의 문자열
- 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일
- 동작과정
- 브라우저(클라이언트)가 서버에 요청(접속)을 보낸다.
- 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
- 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
Session
- 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리
- 동작과정
- 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다.이때, 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
- 서버에서 브라우저에 쿠키에 Session Id를 저장한다.
- 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 요청에 Session Id를 쿠키에 담아 전송한다.
- 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.
Token
- 인증받은 사용자들에게 발급하는 것
- 토큰 기반 인증 시스템은 세션 기반 인증 시스템과 달리 상태를 유지하지 않기때문에 stateless한 구조를 가짐
- 앱과 서버가 통신 및 인증할 때 가장 많이 사용됨
- 동작과정
- 토큰기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여
- 이 토큰은 유일하며 토큰을 발급 받은 클라이언트는 다시 서버에게 요청을 보낼 때 요청 헤더에 토큰을 심어 보냄
- 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치여부를 체크하여 인증 과정을 처리함
JWT (JSON Web Token)
JWT란?
- JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 claim 기반의 Web Token
- 인증에 필요한 정보들을 암호화시킨 토큰임
JWT 구조
- Header: 토큰의 타입을 지정하는 typ과 알고리즘을 지정하는 alg로 구성
- Payload: 토큰에서 사용할 정보인 claim을 담고 있음. claim에는 JSON 형태로 다수의 정보가 담길 수 있음
- Signiture: 토큰을 인코딩하거나 유효성을 검증할 때 사용하는 고유한 암호화 코드
JWT 인증 과정
- 사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청한다.
- 서버가 Header, Payload, Signature를 정의한다. Header, Payload, Signature를 각각 Base64로 암호화하여 JWT를 생성하고 이 정보를 쿠키에 담아 클라이언트에게 발급한다.
- 클라이언트는 서버로부터 받은 JWT를 로컬에 저장하고 API를 서버에 요청할 때 Authorization header에 Access Token을 담아서 보낸다.
- 서버는 클라이언트가 Header에 담아서 보낸 JWT가 해당 서버에서 발 행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과시키고 일치하지 않는다면 통과시키지 않는다. 인증이 되면 Payload에 있는 유저의 정보를 찾아서 클라이언트에 반환한다.
- 클라이언트가 서버에 요청을 했는데 AccessToken이 만료된 상태라면 클라이언트는 Refresh Token을 이용해서 서버로부터 새로운 Access Token을 발급 받는다.
JWT 장점
- Header와 Payload를 이용해 Signature를 생성하므로 데이터 위∙변조 를 막을 수 있음
- 인증 정보를 위한 별도의 저장소가 필요 없음
- 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증되었음을 증명하는 데에 필요한 모든 정보를 자체적으로 가지고 있음
- 서버가 stateless해서 서버를 확장하기에 용이함
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유 가능
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서 비스에서도 로그인 가능
- 모바일 애플리케이션 환경에서도 동작
JWT 단점
- 토큰 자체에 정보를 담고 있으므로 그에 따른 위험도 존재
- 토큰의 Payload에 3종류의 claim을 저장하므로 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있음
- Payload 자체는 암호화 된 것이 아니라 Base64로 인코딩 된 것이므로 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있음 → Payload에 중요 데이터를 넣지 말아야 됨
- 서버가 stateless해서 토큰은 클라이언트 측에서 관리, 저장하기 때문에 토큰 자체를 탈취당하면 대처하기 어려움
Access Token과 Refresh Token
- 토큰의 탈취 위험이 있기 때문에 Access Token, Refresh Token 이중으로 나누어 인증하는 방식을 주로 이용
- Access Token: 클라이언트가 가지고 있는, 유저의 정보가 담긴, 접근에 필요한 토큰. 서버에 클라이언트로부터 요청이 오면, 해당 토큰에 있는 정보를 이용하여 유저의 정보에 맞게 응답
- Refresh Token: 새로운 Access Token을 발급해주기 위해 사용되는 토큰
'공부 > 백엔드' 카테고리의 다른 글
[스프링 부트3 백엔드 개발자 되기] - 1일차 (0) | 2024.02.02 |
---|---|
DDD (1) | 2023.11.21 |
Spring Security (0) | 2023.11.02 |
싱글톤 (Singleton) (0) | 2023.09.16 |
자바 ORM 표준 JPA 프로그래밍 CH08 (프록시와 연관관계 관리) (0) | 2023.07.17 |