이번에 사이드프로젝트를 진행하면서 맨 처음 로그인을 담당하는 기능을 Spring Security, JWT를 이용하여 RestAPI 기반으로 만들어 보았다.
먼저 왜 사용해야하는지를 알아야했다.
1. Spring Security란?
Spring Security는 인증, 권한부여 및 일반적인 공격에 대한 보호를 제공하는 프레임워크이다.
필수 어플리케이션과 반응형 어플리케이션 모두를 보호하기위한 Spring 기반 표준 보안이다.
공식문서를 참고해보니 Spring 웹 어플리케이션을 구축 할 때 공격을 막기 위한 표준 보안이다.
2. JWT(JSON Web Token)란?
위 공식 문서를 참고하면 JWT는 정보를 안전하게 전송하기위한 표준 방식으로 JSON형식으로 이루어진 독립적이고 간결한 방식이며 클레임 이라고하는 JWT내의 정보들을 이용하여 토큰을 받는 측에서 검증하여 신뢰 할 수 있는 데이터로 활용하는 것을 말한다.
JWT는 기본적으로
와 같은 "." 으로 구분 된 구조를 가지고 맨 오른쪽 x영역이 Header, y영역이 payload, z영역이 signature이다.
- Header
헤더는 토큰의 타입과 암호화에 사용 된 알고리즘의 종류를 확인 할 수 있다.
- Payload
페이로드는 사용자에 대한 정보 및 추가적인 데이터에대한 부분이다.
페이로드 및 헤더는 언제든지 디코딩되어 읽을 수 있기때문에 중요한 정보를 넣으면 안된다.
- Signature
signatrue는 인코딩 된 헤더, 인코딩 된 페이로드, secret key(비밀키), 헤더에 특정 알고리즘을 사용하여 암호화 한 데이터이다.
sigature는 토큰의 정보가 변경되지 않았는지 확인하는데 사용한다.
3. 그렇다면 왜 JWT방식을 사용할까?
흔히 웹 개발 시 로그인 방식은 JWT와 세션방식이 있다. 각 방식의 장단점을 확인해보자.
세션방식 인증
먼저 세션방식의 인증의 flow는 다음과 같다
출처 - https://sherryhsu.medium.com/session-vs-token-based-authentication-11a6c5ac45e4
세션방식 인증은 사용자가 로그인 하게되면 해당 사용자에대한 세션ID를 생성하여 쿠키에 저장한다. 로그인 상태를 유지하는동안 쿠키에 저장된 세션ID로 메모리에 저장 된 세션 정보를 비교하여 사용자의 신원을 확인하고 응답을 보내는 형식이다.
- 장점
- 서버에 세션정보를 저장하기 때문에 관리하기 편하다.
- 서버에서 로그인 정보를 확인 할 수 있다.
- 단점
- 서버에서 클라이언트의 상태를 저장 하고 있으므로 클라이언트의 수가 많아지면 메모리나 기타 저장소에 부하가 증가한다.
- 위 단점을 보완하기위해 서버를 확장 하게 될때 세션의 관리가 어려워진다.
- 멀티 디바이스 환경에서 로그인 할 때 중복 로그인 처리 등의 신경써야 할 부분들이 생긴다.
- 쿠키는 단일 도메인 및 서브 도메인에서만 작동하기 때문에 여러 도메인으로 관리 할 시CORS(Cross-Origin Resource Sharing)를 해결해야한다.
토큰방식 인증
토큰 기반으로 인증을 하게되면 세션 대신 JWT(JSON Web Token)을 사용하게된다.
이는 모든 요청의 헤더에 JWT를 포함하여 클라이언트의 모든 요청에 대해 JWT의 유효성을 검사하여 응답을 보내는 방식이다.
- 장점
- 토큰 기반인증은 한번 발급해준 JWT토큰을 클라이언트가 서버에 요청 할 때마다 해당 토큰을 전달하면 되기때문에 클라이언트에 토큰이 저장되어 서버에 부담을 주지 않는다.
- 발급받은 토큰을 여러 서버에서 인증 할 수 있으므로 서버 확장시 효율적으로 인증 할 수 있다.
- 멀티 디바이스 환경에 대한 부담이 없다.
- 단점
- 만약 토큰을 탈취 당할 시 해당 사용자의 권한을 그대로 가질 수 있다.
-> 해결책으로 토큰의 유효기간을 짧게 하거나 Refresh Token을 생성하여 JWT(Access Token)을 재발급 받도록 하는 방법도 있다. - Header 및 Payload영역에서의 데이터는 base64로 인코딩 된 데이터 이므로 해당 데이터를 디코딩을 통해 볼 수 있다.
