🌈 [Section4] 4. [ Spring Security ] JWT 인증

📕 오늘 배운 내용!

• 세션 기반 인증 vs 토큰 기반 인증
• JWT

---

✏️ 세션 기반 인증

• 서버 or DB에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장 하는 방식
  
  
• 인증된 사용자의 상태를 유지하기 위한 전통적인 방식
  ( 사용자의 고유 세션 ID가 클라이언트의 쿠키에 저장되어 인증 수단으로 사용 )
  
  
• 상대적으로 적은 네트워크 트래픽 사용
  ( 세션 ID만 클라이언트 쪽에서 사용하기 때문 )
  
  
• 보안성 측면에서 조금 더 유리
  ( 서버 측에서 세션 정보를 관리하기 때문 )
  
  
• 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높음
  ( 인증된 사용자 request의 상태를 유지해야하기 때문 )
  ➜ Sticky Session, Session Clustering, Session 저장소의 외부 분리 등의 작업을 통해 보완

[Sticky Session과 Session Clustering 참고]
[Sticky Session 참고]
[Session Clustering 참고 1], [Session Clustering 참고 2]

• 세션 데이터가 많아질수록 서버의 부담이 가중
  
  
• SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식

❗ HTTP 프로토콜의 특징인 비연결성(Connectionless) / 비상태성(Stateless)을 보완하여, 인증된 사용자의 request의 상태를 유지하기 위한 수단이 세션

---

✔ 세션 기반 인증 절차

---

✏️ 토큰 기반 인증

• 토큰에 포함된 인증된 사용자 정보를 서버 측에서 별도로 관리 X
  
  
• 사용자 인증 정보가 포함된 토큰을 헤더에 포함시켜서, request 전송 시 인증 수단으로 사용
  
  
• 세션에 비해 상대적으로 많은 네트워크 트래픽 사용
  ( 토큰 내에 인증된 사용자 정보 등을 포함하기 때문 )
  
  
• 보안성 측면에서 조금 더 불리
  ( 서버 측에서 토큰을 관리하지 않기 때문 )
  
  
• 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제 발생 X
  ( 인증된 사용자 request의 상태를 유지할 필요가 없기 때문 )
  
  
• 민감한 정보는 토큰에 포함시키지 말아야 함
  ( 토큰에 포함되는 사용자 정보는 토큰 특성상 암호화 X이기 때문 )
  
  
• 토큰이 만료되기 전까지는 무효화 X
  ➜ key/value 쌍의 형태로 저장되는 Redis 같은 인메모리 DB에 무효화 시키고자 하는 토큰의 만료 시간을 짧게 주어 해당 토큰을 사용하지 못하게 하는 등의 방법 사용하여 보완
  
  
• CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식

---

✔ 토큰 기반 인증 절차

Ex. 로그인 요청을 가정하면,

① 클라이언트 ➜ 서버
👉 Username/Password 담아 로그인 요청

② 서버 - DB
👉 Username/Password 가 일치하는지 확인
⠀
👉 클라이언트에게 보낼 암호화 된 토큰 생성

• Access Token / Refresh Token 모두 생성
• 토큰에 담길 정보(Payload)는 사용자를 식별할 정보, 사용자의 권한 정보 등
• Refresh Token을 이용해 새로운 Access Token을 생성할 것이므로 두 종류의 토큰이 같은 정보를 담을 필요는 X
  
  

③ 서버 ➜ 클라이언트
👉 토큰 전송

④ 클라이언트
👉 토큰 저장
( 저장하는 위치는 Local Storage, Session Storage, Cookie 등 )

----------------------------------- ( 이 후, 다음 요청에서 ) -----------------------------------

⑤ 클라이언트 ➜ 서버
👉 HTTP Header(Authorization Header) or 쿠키에 토큰을 담아 request 전송
( Bearer authentication 이용 )

[Bearer authentication 참고]
요약 - https://learning.postman.com/docs/sending-requests/authorization/#bearer-token
상세 - https://www.rfc-editor.org/rfc/rfc6750

⑥ 서버
👉 토큰 검증 후, 일치할 경우 요청 처리 후 응답
( 서버가 발급했던 토큰이 맞을 경우, 클라이언트의 요청을 처리 후 응답 보냄 )

---

✏️ JWT (Json Web Token)

[JWT 공식 사이트]

• Json 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰
• 데이터를 안전하고 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식
• 토큰 인증 방식에서 가장 범용적으로 사용
• JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명(Sign)한 메시지를 Web Token으로써 인증 과정에 사용

[참고] https://jwt.io/introduction

---

✔ JWT 종류

✔️ 액세스 토큰 (Access Token)

• 보호된 정보들(사용자의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용
• 클라이언트가 처음 인증을 받게 될 때(로그인 시), Access Token과 Refresh Token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 Access Token
• 탈취되더라도 오랫동안 사용할 수 없도록 비교적 짧은 유효기간
  ➜ 유효기간이 만료된다면 Refresh Token을 사용하여 새로운 Access Token을 발급받음
  ( 다시 로그인 인증 필요 X )

✔️ 리프레시 토큰 (Refresh Token)

• Access Token 발급받을 때 사용
• 긴 유효기간
  ➜ But, 유효기간이 길어 탈취당한다면 큰 피해가 올 수 있기 때문에,
  사용자의 편의보다 정보를 지키는 것이 더 중요한 웹 애플리케이션은 Refresh Token을 사용하지 않는 곳이 많음

[Refresh Token 발급 기간 참고]

❗ 세상에 완벽한 보안은 없으므로 각 장단점을 참고하여 필요에 맞게 사용하기

---

✔ JWT 구조

( . 을 기준으로 Header / Payload / Signature 세 부분으로 나뉨 )

✔️ Header

• 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 암호화할지 정의
  ( JSON 포맷 형태로 정의 )
• JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성
  
  

✔️ Payload

• 서버에서 활용할 수 있는 사용자의 정보가 담겨있음

Ex. 접근 권한 / 사용자 데이터 등

• 민감한 정보는 담지 않는 것이 좋음

Ex. password

• JSON 객체를 base64 방식으로 인코딩하면 JWT의 두 번째 부분이 완성
  
  

✔️ Signature
( base64로 인코딩된 첫 번째, 그리고 두 번째 부분이 완성되었다면, )

• 원하는 비밀 키(Secret Key) + Header에서 지정한 알고리즘을 사용하여 Header와 Payload에 대해서 단방향 암호화 수행
  ⠀
  ➜ 암호화 된 메시지는 토큰의 위변조 유무를 검증하는데 사용

Ex. HMAC SHA256 알고리즘(암호화 방법 중 하나) 사용한다면,
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);
이와 같은 방식으로 Signature가 생성됨

---

✔ JWT 인증의 장점

• 무상태성 (Statelessness) & 확장성 (Scalability)
  • 클라이언트에 대한 정보 저장할 필요 X / 토큰이 정상적으로 검증되는지만 판단
    ➜ 서버와 DB의 부담 덜어줌
  • 클라이언트가 request 전송할 때 마다 헤더에 토큰을 포함시켜 전송
    ➜ 하나의 토큰으로 여러 서버에 인증 가능
    ( 세션 방식이라면 모든 서버가 해당 사용자의 세션 정보를 공유하고 있어야 함 )
    
    
• 클라이언트가 request를 전송할 때 마다 인증 정보 전송할 필요 없음
  • 토큰이 만료되기 전까지는 인증은 한번만 수행
    ( HTTP Basic 같은 인증 방식은 request를 전송할 때 마다 인증 정보를 포함해야함 )
    
    
• 안정성
  • 암호화한 토큰 사용
  • 암호화 키를 노출할 필요 X
    
    
• 어디서나 생성 가능
  • 토큰을 생성하는 서버가 꼭 그 토큰을 만들지 않아도 되고,
    토큰 생성용 서버를 만들거나, 다른 회사에서 토큰 관련 작업을 맡기는 것 등 다양한 활용 가능
  • 사용자의 자격 증명 정보를 직접 관리하지 않고, 다른 플랫폼의 자격 증명 정보로 인증 가능
    Ex. Github / Google 등
    
    

• 권한 부여에 용이
  • 토큰의 Payload 안에 해당 사용자의 권한 정보를 포함하는 것이 용이

---

✔ JWT 인증의 단점

• Payload 디코딩이 용이
  ➜ 탈취하여 디코딩 후 데이터 확인이 가능하기 때문에 민감한 정보는 포함 X
  
  
• 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있음
  ➜ 토큰에 저장하는 정보의 양이 많아질 수록 토큰의 길이는 길어지기 때문에
  request 전송 시 마다 긴 토큰 전송하면 네트워크에 부하를 줄 수 있음
  
  
• 토큰은 자동으로 삭제되지 않음
  ➜ 또, 탈취될 가능성이 있기에 반드시 길지 않은 토큰 만료 기간 추가하기

---

✏️ JWT를 이용한 로그인 인증 흐름

( 사용자의 로그인 인증 성공 후, JWT가 클라이언트에게 전달되는 과정 )

① 클라이언트가 서버 측에 로그인 인증 요청(Username/Password를 서버 측에 전송)

💬 클라이언트 :
서버야, 이 Username/Password로 로그인 인증 좀 해줘

② 로그인 인증을 담당하는 Security Filter(JwtAuthenticationFilter)가 클라이언트의 로그인 인증 정보 수신

💬 Security Filter (JwtAuthenticationFilter) :
OK 내가 받음.

③ Security Filter가 수신한 로그인 인증 정보를 AuthenticationManager에게 전달해 인증 처리를 위임

💬 Security Filter (JwtAuthenticationFilter) :
야 AuthenticationManager, 로그인 인증 정보 줄테니까 네가 대신 인증 처리해.

④ AuthenticationManager가 Custom UserDetailsService(MemberDetailsService)에게 사용자의 UserDetails 조회를 위임

💬 AuthenticationManager :
OK 내가 함.
야 UserDetailsService(MemberDetailsService), 이 사용자 UserDetails 조회 한번 해봐라.

 

⑤ Custom UserDetailsService(MemberDetailsService)가 사용자의 크리덴셜을 DB에서 조회한 후, AuthenticationManager에게 사용자의 UserDetails를 전달

💬 UserDetailsService (MemberDetailsService) :
OK 내가 함.
야 AuthenticationManager, 그 사용자 크리덴셜 조회해봤더니 이 UserDetails 나왔어.
너 줄게.

 

⑥ AuthenticationManager가 로그인 인증 정보와 UserDetails의 정보를 비교해 인증 처리

💬 AuthenticationManager :
OK 받음.
그럼 내가 아까 Security Filter(JwtAuthenticationFilter)가 준 로그인 인증 정보랑 네가 준 UserDetails랑 비교해서 같은 사용자인지 볼게.

⑦ JWT 생성 후, 클라이언트의 응답으로 전달

💬 AuthenticationManager :
같은 사용자인 거 인증 됐으니까 JWT 생성해서 응답으로 줄게.

❗ 우리는 여기서
JwtAuthenticationFilter(②,③,⑦) / MemberDetailsService(⑤) 구현
( ④,⑥은 Spring Security의 AuthenticationManager가 대신 처리해 줌 )

---

😜 실습

• projects - be-template-spring-security-jwt-basic

✔ JWT 자격 증명을 위한 사전 작업

1. 의존 라이브러리 추가

implementation 'org.springframework.boot:spring-boot-starter-security' // (1) Spring Security 적용하기 위해
⠀⠀
// (2) JWT 기능을 위한 jjwt 라이브러리 ( Spring Security 기반의 애플리케이션에 JWT 적용하기 위해 )
implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'
runtimeOnly	'io.jsonwebtoken:jjwt-jackson:0.11.5'

❗ JWT를 적용하기 위해서는 jjwt나 Java JWT 같은 별도의 라이브러리가 필요
[jjwt 참고] / [java-jwt 참고] (https://github.com/auth0/java-jwt)

2. SecurityConfigurationV1 클래스 추가
[CORS 참고 1], [CORS 참고 2]

3. 회원 가입 로직 수정

    3-1. MemberDto.Post 클래스에 패스워드 필드 추가

    3-2. Member 엔티티 클래스에 패스워드 필드 추가

    3-3. MemberService 클래스에 사용자 등록 시, 패스워드와 사용자 권한 저장

    3-4. CustomAuthorityUtils 클래스 추가
    ➜ MemberService 클래스에 DI 하기 위함

---

✔ JWT 자격 증명을 위한 로그인 인증 구현

❗ 핵심
➜ 사용자의 Username(이메일 주소)과 Password 로 로그인 인증에 성공하면,
로그인 인증에 성공한 사용자에게 JWT 를 생성 및 발급하는 것

1. MemberDetailsService 클래스 추가
➜ Custom UserDetailsService 구현

2. LoginDto 클래스 추가
➜ 클라이언트의 Username + Password 정보만 담는 단순한 DTO 클래스
➜ 로그인 인증 정보 역직렬화(Deserialization)를 위함

3. JwtTokenizer 클래스 추가
➜ JWT 생성

4. JwtAuthenticationFilter 클래스 추가 ( Custom Security Filter )
➜ 로그인 인증 요청 처리

5. SecurityConfigurationV2 클래스에 설정 추가
➜ Custom Filter 추가를 위해
➜ JwtAuthenticationFilter 를 Spring Security Filter Chain 에 추가해서 로그인 인증을 처리하도록

🔊 이 후, postman으로 member 등록 후,
/v11/auth/login 경로로 username / password post하면 로그인이 인증되어
Headers 탭에서 Authorization 키의 값으로 Access Token,
Refresh 키의 값으로 Refresh Token 포함되어 나타남
⠀
➜ 클라이언트 쪽에서 서버 측의 리소스를 사용하기 위한 request 전송할 때 마다
전달 받은 JWT 를 request header 에 포함 후,
클라이언트의 자격 증명 정보로 사용하면 됨 !

---

✔ 로그인 인증 성공 및 실패에 따른 추가 처리

1. AuthenticationSuccessHandler 클래스 추가
➜ 로그를 기록 or 로그인에 성공한 사용자 정보를 response로 전송하는 등의 추가 처리
[AuthenticationSuccessHandler 참고]

2. AuthenticationFailureHandler 클래스 추가
➜ 로그인 인증 실패 시에도 마찬가지로 인증 실패에 대해 추가 처리 가능
[AuthenticationFailureHandler 참고]

3. SecurityConfigurationV3 클래스에 설정 추가
➜ AuthenticationSuccessHandler / AuthenticationFailureHandler 추가

❗ AuthenticationSuccessHandler 인터페이스와 AuthenticationFailureHandler 인터페이스의 구현 클래스를 JwtAuthenticationFilter 에 등록하면 로그인 인증 시, 두 핸들러 사용 가능

4. JwtAuthenticationFilter 클래스에 설정 추가
➜ AuthenticationSuccessHandler 호출 코드 추가

---

✔ JWT 검증 기능 구현

➜ 자격 증명이 필요한 request 전송 시, request header 를 통해 전달받은 JWT 를 서버 측에서 검증하는 기능 구현

1. JwtVerificationFilter 클래스 추가
➜ 클라이언트 측에서 전송된 request header 에 포함된 JWT 의 검증 작업 수행
➜ 서버 측에서 response header 에 JWT 를 포함해 전송한 후 클라이언트가 다시 요청보낼 때,
그 JWT 를 request header 에 포함하여 전송할 경우에 서버가 보낸 JWT 가 맞는지 검증하는 과정임

2. SecurityConfigurationV4 클래스에 설정 추가
➜ JwtVerificationFilter를 사용하기 위해 세션 정책 설정 + JwtVerification 추가

❗ 1번에서 검증 성공하면 Authentication 객체를 SecurityContext에 저장하는데
stateless 특징을 유지하기 위해 세션 유지 기간을 아주 짧게(거의 무상태) 주기 위해 설정 추가

3. SecurityConfigurationV5 클래스 추가
➜ SecurityConfigurationV4 + 접근 권한 설정

❗ SecurityConfigurationV4 클래스는 접근 권한이 .anyRequest().permitAll() 로 되어있어 모두 접근 가능

---

✔ 예외 처리 로직 추가

지금까지는 JwtVerificationFilter에서 SignatureException과 ExpiredJwtException에 대해 어떤 처리도 하지 않고 있음

✔️ SignatureException
➜ JWT 에 대한 서명(Signature) 검증에 실패할 경우 throw되는 예외

---

✔️ ExpiredJwtException
➜ JWT 가 만료될 경우 throw되는 예외

 

1. JwtVerificationFilter 클래스에 예외 처리 로직 추가
➜ JWT 검증 과정에서 발생할 수 있는 Exception을 처리할 수 있도록
[AuthenticationEntryPoint 참고]

2. MemberAuthenticationEntryPoint 클래스 추가
➜ AuthenticationException이 발생할 때 호출되는 핸들러 같은 역할
➜ 여기서는 AuthenticationException 발생하면 ErrorResponse 를 생성해서 클라이언트에게 전송하도록 구현

✔️ AuthenticationException
➜ 대표적으로 SecurityContext 에 Authentication 이 저장되지 않았을 때 발생하는 에러

3. ErrorResponse 클래스 추가
➜ AuthenticationException 발생하면 클라이언트에게 전송할 클래스

4. MemberAccessDeniedHandler 클래스 추가
➜ 인증에는 성공했지만 해당 리소스에 대한 권한이 없을 경우 호출되는 핸들러
[ AccessDeniedHandler 참고 ]

5. SecurityConfiguration 클래스 추가
➜ MemberAuthenticationEntryPoint / MemberAccessDeniedHandler 사용할 수 있도록 추가

❗ Username/Password 기반의 로그인 인증은 OncePerRequestFilter 같은 Spring Security에서 지원하는 다른 Filter 이용해서도 구현 가능하고,
Controller에서 REST API 엔드포인트로 구현하는 것도 가능함

[OncePerRequestFilter 참고 1], [OncePerRequestFilter 참고 2]

---

🌈 느낀점

그래도 Spring Security 기본에서 배웠던 거에 더해져서 배우니 그래도 낫다 ..!
하지만 여전히 어려움 ..

 

( 본 게시물은 2022/11/24에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90