📌 우선 세션기반 자격증명과 토큰 기반 자격증명에 대해 알아보자
✅ 세션 기반 자격 증명
JWT는 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식이다.
세션 기반 자격증명 특징
- 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.
- 생성된 사용자 세션의 고유한 ID인 세션ID는 클라이언트의 쿠키에 저장되어 요청을 보낼 때 인증된 사용자인지를 증명하는 수단으로 사용된다.
- 클라이언트 측에서는 세션 ID만을 사용하기 때문에, 네트워크 트래픽 부담이 비교적 적다.
- 세션 정보는 서버 측에서 관리 되기 때문에, 보안 측면에서 약간의 이점이 있다.
- 서버 확장성 측면에서는 세션 불일치 문제가 발생할 가능성이 있다.
- 세션 데이터 양이 증가하면서 서버 부하가 증가할 수 있다.
- SSR(Server Side Rendering) 애플리케이션에 적합하다
✅ 토큰 기반 인증
세션 기반 인증방식으로는 생기는 서버의 부담을 "클라이언트에게 넘겨줄 수는 없을까?"하는 생각에서 토큰 기반 인증이 고안되었다.
- 클라이언트 측에 인증된 사용자의 정보를 토큰 형태로 저장하는 방식
- 토큰 : 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근할 수 있게 해주는 역할.
🤔 로그인을 할 수 있는 열쇠?라고 하면 이해가 쉬울까...?
토큰 기반 자격증명 특징
- 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도로 관리되지 않는다.
- 생성된 토큰을 헤더에 포함시켜 요청을 보낼 때, 인증된 사용자인지를 증명하는 수단으로 사용된다.
- 토큰은 인증된 사용자 정보 등을 포함하기 때문에 세션보다 비교적 많은 네트워크 트래픽을 사용한다.
- 토큰은 기본적으로 서버측에서 관리되지 않기 때문에 보안측면에서 약간의 불리함이 있다.
- 토큰은 기본적으로 만료될때까지 무효화 될 수 없다.
- CSR(Client Side Rendering) 기반 애플리케이션에 적합한 방식이다.
📌 JWT ( JSON Web Token )
✔ 가장 범용적으로 사용되는 토큰 인증 방식이다.
✔︎ JSON 포맷의 토큰 정보를 인코딩 후, 인코딩된 토큰 정보를 Secret Key로 서명(Sign)한 메시지를 Web Token으로써 인증과정에서 사용하는 것이다.
✅ JWT 종류
액세스 토큰 (Access Token)
- 보호된 정보들 ( 사용자의 이메일, 연락처, 사진 등 )에 접근할 수 있는 권한 부여에 사용
- 비교적 짧은 유효기간을 주어 탈취되더라도 오랫동안 사용할 수 없도록한다.
리프레쉬 토큰 ( Refresh Token )
- Access Token의 유효기간이 만료된다면 Refresh Token을 사용하여 새로운 Access Token을 발급받는다. (재발급을 의미??)
- 이때, 사용자는 다시 로그인 인증할 필요가 없다.
- Refresg Token을 탈취 당한다면 Access Token을 계속 발급할 수 있기 때문에 보안상의 문제가 있다.
- 사용자의 편의보다 정보를 지키는 것이 더 중요한 웹 애플리케이션은 Refresh Token을 사용하지 않는 것이 좋다.
✅ JWT 구조
✔︎ Header
- 어떤 종류의 토큰인지 (지금의 경우에는 JWT), 어떤 알고리즘으로 Sign할 것인지 정의
- JSON 객체를 base64방식으로 인코딩하면 JWT구조 중 첫 번째 부분이 완성된다.
✔︎ PayLoad
- 서버에서 활용할 수 있는 사용자의 정보(실질적인 데이터)가 담겨있다.
Ex. 접근권한 / 사용자데이터 - 민감한 정보는 담지 않는 것이 좋다.
Ex. Password - JSON 객체를 base64방식으로 인코딩하면 JWT구조 중 2번째 두분이 완성
✔︎ Signature
원하는 비밀 키(Secret Key)+Header에서 지정한 알고리즘을 사용하여 Header와 PayLoad에 대해서 단방향 암호화 수행
→ 암호화 된 메시지는 토큰의 위변조 유무를 검증하는데 사용
✅ JWT를 이용한 로그인 인증 흐름
(사용자 로그인 성공 후, JWT가 클라이언트에게 전달되는 과정)
1️⃣ 클라이언트가 서버측에 로그인 인증 요청(Username/Password)
📢 Client
서버야, Username/Password 인증 부탁해
2️⃣ 로그인 인증을 담당하는 Security Filter(JwtAuthenticationFilter)가 클라이언트의 로그인 인증 정보를 수신 후
AuthenticationManager에게 인증처리를 위임
💬 Security Filter(JwtAuthenticationFilter)
오케이 내가할게.
📢 Security Filter(JwtAuthenticationFilter)
AuthenticationManager, 로그인 인증 정보 줄테니까 네가 대신 인증 처리해.
3️⃣ AuthenticationManagerk CustomUserDetailsService에게 사용자의 UserDetails조회를 위임
💬 AuthenticationManager
오케이 내가할게.
📢 AuthenticationMaanger
CustomUserDetailsService, 받은 사용자 UserDetails조회 좀 해줘
4️⃣ CustomUserDetailsServce가 사용자의 Credential을 DB에서 조회한 후, AuthenticationManager에게 사용자의 UserDetails 전달
💬 CustomUserDetailsServcie
오케이 기다려 조화해줄게
📢 CustomUserDetailsServcie
자 결과 보내줄게 받아.
5️⃣ AuthenticationManager가 로그인 인증정보와 UserDetails의 정보를 비교해 인증 처리
💬 AuthenticationManager
고마워, 너가 준거랑 Security Filter(JwtAuthenticationFilter)가 준 거랑 같은 사용자인지 확인해볼게
6️⃣ JWT 생성후, 클라이언트의 응답으로 전달
💬 AuthenticationManager
클라이언트야 인증 성공했어. JWT생성해서 Response해줄게
