[Spring Security] Session 기반 인증 방식 VS Token 기반 인증 방식

 

먼저, `스프링 시큐리티`는 스프링 프레임워크에서 애플리케이션의 인증(Authentication)과 인가(Authorization)를 쉽게 구현할 수 있도록 도와주는 보안 라이브러리입니다. 주로 웹 애플리케이션이나 Rest Api 에서 사용자 인증과 접근 제어를 관리하는데 사용됩니다.

 

 

스프링 시큐리티의 주요 기능

1. 인증(Authentication) : 사용자가 누구인지 확인하는 절차입니다. ex) 로그인 폼에서 사용자 아이디와 비밀번호를 입력받아 검증하는 방식입니다.
2. 인가(Authorization) : 인증된 사용자가 어떤 기능이나 자원에 접근할 수 있는지를 결정합니다. 즉, 유저에 대한 권한을 허락하는 것입니다. ex) 관리자만 접근 할 수 있는 페이지 설정 등이 가능합니다.
3. 세션 및 토큰 관리 : 세션 기반 인증 또는 JWT 같은 토큰 기반 인증을 쉽게 구성할 수 있습니다.
4. OAuth2 및 소셜 로그인 지원 : 구글, 페이스북, 마이크로소프트 같은 외부 인증 서비스와 연동하여 간편 로그인 기능을 구현할 수 있습니다.
5. 보안 설정 커스터마이징 : URL별 접근 권한, 요청 방식(GET, POST 등)에 따른 권한 제어 등을 세밀하게 설정할 수 있습니다.

 

스프링 시큐리티의 장점

1. 구현이 간편함 : 스프링 부트와 통합하여 기본적인 인증 및 권한 부여 기능을 쉽게 설정할 수 있습니다.
2. 유연성 : 기본 설정 외에도 다양한 확장 기능을 커스터마이징 할 수 있어 복잡한 요구 사항도 충족할 수 있습니다.
3. 안정성 : 비밀번호 암호화, CSRF(Cross-Site Request Forgery) 보호, CORS(Cross-Origin Resource Sharing) 설정 등을 통해 보안 강화에 도움이 됩니다.

---

이러한 스프링 시큐리티에서는 `세션 기반 인증`과 `토큰 기반 인증`이 있습니다.

 

두 방식의 주요 차이점은 서버 상태 유지 방식과 요청마다 인증 정보를 처리하는 방식에 있습니다.

 

세션 기반 인증

`세션 기반 인증`은 서버가 세션을 통해 사용자의 인증 상태를 유지하는 방식입니다.

 

동작 방식 : 사용자가 로그인에 성공하면 서버는 `세션 ID`를 생성하여 클라이언트에 쿠키로 전달합니다. 이후 요청에서 클라이언트는 이 세션 ID를 함께 보내며, 서버는 이를 통해 사용자가 인증되었음을 확인합니다.

 

장점

• 서버에서 세션 정보를 유지하므로 각 요청에서 인증을 반복할 필요가 없습니다.
• 스프링 시큐리티와 함께 HttpSession을 이용하여 쉽게 구현할 수 있습니다.

단점

• 서버가 세션 정보를 저장하고 관리해야하므로 서버 메모리를 사용합니다.
• 서버가 스케일 아웃(여러 서버로 확장)될 때, 각 서버가 같은 세션을 공유해야 해서 추가 설정이 필요합니다.

 

토큰 기반 인증

`토큰 기반 인증`은 주로 REST API 환경에서 많이 사용되는 방식으로, 서버에서 상태를 유지하지 않습니다.

 

동작 방식 : 사용자가 로그인하면 서버는 `JWT(JSON Web Token)` 또는 `OAuth 토큰`을 발급하여 클라이언트에 전달합니다. 이후 클라이언트는 요청마다 이 토큰을 헤더에 포함해 전송하며, 서버는 토큰을 검증하여 사용자를 인증합니다.

 

장점

• 서버가 인증 상태를 저장할 필요가 없어 확장성이 좋습니다.
• REST API와 같이 무상태(stateless) 통신을 할 때 적합합니다.
• 클라이언트가 여러 플랫폼(웹, 모바일)인 경우에도 동일한 방식으로 인증할 수 있습니다.

단점

• 토큰을 클라이언트에서 저장해야하므로, 보안에 주의해야합니다. 특히 만료된 토큰이 재사용되지 않도록 적절히 관리해야합니다.
• 토큰의 크기가 커질 수 있어 요청마다 네트워크 부하가 있을 수 있습니다.

 

선택 기준은 주로 애플리케이션의 아키텍처에 따라 다릅니다. 세션 기반은 서버 상태를 유지하는 웹 애플리케이션에 적합하고, 토큰 기반은 REST API와 같은 무상태 통신을 선호하는 환경에 적합합니다.