3. Jwt의 사용 이유 (Spring Security)

0. 프로젝트 소개(Spring Security) 및 Security에 대하여

 

1. User Entity 생성(Spring Security)

 

2. User 회원가입 (Spring Secureity)

 

3.Jwt의 사용 이유 (Spring Security)

 

4. Authorization(인증)

• 4-0 Authorization(인증) - 프로세스 설명
• 4-1 Authentication(인증) - UserDetails, UserDetailsService 및 JwtService 생성
• 4-2 Authentication(인증) - UsernamePasswordAuthenticationfilter 생성
• 4-3 Authentication(인증) - CorsFilter(선택사항)
• 4-4 Authentication(인증) - SecurityConfig

5. Authorization(인가)

• 5-1 Authorization(인가) - Jwt 인가 관련 에러 처리
• 5-2 Authorization(인가) - Jwt 인가 서비스 로직 추가
• 5-3 Authorization(인가) - AuthorizationFilter 생성
• 5-4 Authorization(인가) - SecurityConfig에 인가 관련 method 추가

6. OAuth

• 6-0 OAuth에 대해서
• 6-1 OAuth 2.0 - 사전 설정
• 6-2 OAuth2.0 - DTO 설정
• 6-3 OAuth2.0 - OAuth2UserService
• 6-4 OAuth2.0 - OAuth2UserService
• 6-5 OAuth2.0 - 필터 생성 및 SecurityConfig 수정

 

Http의 특징(비상태성)

우리가 사용하는 http는 stateless 즉 비상태성이라는 특징을 가지고 있다. 클라이언트의 데이터를 서버에서는 따로 관리하지 않기 때문에 사용자의 인증이 필요한 서비스에서 항상 사용자의 정보를 넘겨주는 행위(로그인)을 항상 해줘야하는 불편함을 가지고 있을 뿐더러 클라이언트(브라우저)에 사용자의 정보(아이디 및 비밀번호)를 저장하여 매번 보내기에는 보안이 취약하다는 약점을 가지고 있다.

이를 해결하기 위해서는 session 및 Token을 활용하는 것이 좋다.

 

JWT

Json형태로 이루어진 Web Token이며 브라우저에 토큰의 정보를 저장하여 서버에 요청시 헤더에 토큰의 정보를 실어 인가하는 방식이다.  JWT에는 Header, Payload, Signature로 크게 3가지로 구성되어 있다.

 

Header

• typ: 토큰의 타입을 지정하며 JWT사용시 JWT로 값이 나온다
• alg: Signature 해싱 알고리즘을 지정하며 해싱 알고리즘으로는 보통 HMAC-SHA256 혹은 RSA 가 사용되며, 이 알고리즘은 토큰을 검증 할 때 사용되는 signature 부분에서 사용된다.

Payload

- 토큰에 실어야하는 정보를 담고 있으며 하나의 단위를 claim이라고 한다.

- 클래임의 종류

• 등록된 (registered) 클레임
• 공개 (public) 클레임
• 비공개 (private) 클레임

Signature

•  토큰의 인코딩 및 유효성 검증을 위한 고유 암호화 코드이다. Header와 Payload의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 Header에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성한다.

 

Session이 아닌 JWT를 사용하는 이유

session에 사용자의 정보를 담는것이 더 편함에도 불구하고 jwt를 사용하는 가장 큰 이유는 확장성이다.

 

일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다. 즉, 한대가 아닌 여러대의 서버가 요청을 처리하게 된다. 이때 별도의 작업을 해주지 않는다면, 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다. 이를 해결하기 위해서 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 해주어야한다.

 

하지만, 토큰 기반 인증 방식의 경우 서버가 직접 인증 방식을 저장하지 않고, 클라이언트가 저장하는 방식을 취하기 때문에 이런 세션 불일치 문제로부터 자유롭다. 이런 특징으로 토큰 기반 인증 방식은 HTTP의 비상태성(Stateless)를 그대로 활용할 수 있고, 따라서 높은 확장성을 가질 수 있다.

 

참조: https://hudi.blog/session-based-auth-vs-token-based-auth/