📕 INDEX

1. 인증 방식의 발전

   • 서버(세션) 기반의 인증 시스템
   • 토큰 기반의 인증 시스템

2. Spring Boot - Spring Security 란?

3. 인증 방식의 발전

   소규모 시스템 에서 자주 사용하는 인증 방식 ⇒ 서버(세션) 기반의 인증방식

   <aside> 📌 서버(세션) 기반의 인증 방식

   </aside>

   • 서버 측에서 사용자들의 정보를 기억 : 세션 유지 필요 (메모리 or 디스크 or DB)
   • 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속 유지하고 해당 정보를 서비스에 이용 : Stateful 서버

   

   <aside> 🚨 서버(세션) 기반 인증의 문제점

   </aside>

   웹 / 앱 어플리케이션이 발달하게 됨에 따라 서버를 확장하기 어려워짐.
   

   1. 세션

      세션을 대부분의 경우에 메모리에 저장함. 로그인 중인 사용자가 늘어날 경우 서버의 RAM 에 부하가 발생. DB 에 저장하는 방법 역시 무리가 있음.

   2. 확장성

      사용자가 늘어남에 따라 더 많은 트래픽을 처리하기 위해 서버를 확장해야함. 세션을 사용한다면 세션을 분산시키는 시스템을 설계해야 하지만 과정이 매우 어렵고 복잡함.

   3. CORS(Cross - Origin Resource Sharing)

      웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

   위와 같은 문제들로 인해 토큰 기반의 인증 시스템을 사용하게 되었다.

   <aside> 📌 토큰 기반 인증 시스템

   </aside>

   • 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 한다.
   • 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 구조를 갖는다.
   • 토큰 기반의 인증 방식을 통해 사용자의 로그인 유뮤를 신경쓰지 않고도 손쉽게 시스템 확장이 가능함.

1. 사용자가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 해당 정보를 검증한다.
3. 정보가 정확하다면 서버 측에서 사용자에게 Signed 토큰을 발급한다. (Signed는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 Signature를 가지고 있다는 것)
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달한다. 이때 Http 요청 헤더에 토큰을 포함시킨다.
5. 서버는 토큰을 검증하고, 요청에 응답한다.

<aside> ✅ 토큰 기반 인증 시스템의 이점

</aside>

1. 무상태성(Stateless) & 확장성(Scalability)

   토큰은 클라이언트 측에 저장되어짐. ⇒ Stateless 한 서버 (클라이언트와 서버의 연결고리가 없기 때문에 확장에 매우 적합.)

   만약, 사용자 정보가 서버 측 세션에 저장된 경우에 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 해주어야 한다. 하지만 토큰을 사용한다면 어떠한 서버로 요청이 와도 상관이 없다.

2. 보안성

   클라이언트가 서버로 요청을 보낼 때 쿠키를 전달하지 않으므로, 쿠키 사용에 의한 취약점이 사라진다. (토큰 환경의 취약점이 존재할 수 있으므로 대비 필요.)

3. 확장성(Extensibility)

   시스템의 확장성을 의미하는 Scalability 와 달리 Extensibility 는 로그인 정보가 사용되는 분야 의 확장 을 의미한다.

   • 토큰에 선택적인 권한만 부여하여 발급 가능. or OAuth 의 경우 소셜 계정을 이용하여 다른 웹서비스에서도 로그인이 가능.

• OAuth 란?

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. (위키백과)

• OAuth Flow

Google 등 외부 서비스를 통해 인증을 마치면 클라이언트를 명시된 주소로 리다이렉트 시키는데, 이 때 Query String으로 특별한 Code가 함께 전달됩니다. 클라이언트는 해당 Code와 Client ID 및 Client Secret을 Resource Server에 보내, Resource Server의 자원을 사용할 수 있는 Access Token을 발급 받습니다. 등록되지 않은 리다이렉트 URL을 사용하는 경우, Resource Server가 인증을 거부합니다.

1. 여러 플랫폼 및 도메인

   • 서버 기반 인증 시스템의 문제점 중 하나인 CORS 해결 가능.

     애플리케이션과 서비스의 규모가 커지면 여러 디바이스를 호환시키고 더 많은 종류의 서비스를 제공하게 된다.

   • 토큰을 사용하여 어떤 디바이스나, 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있다.

주로 Json 포맷을 이용하는 JWT(Json Web Token) 을 주로 사용한다고 함.

1. Spring Security 란?

   회원 관리가 필요한 시스템에서 그에 따른 인증(Authentication) 과 인가(Authorization)에 대한 처리가 필요하다. Spring 에서는 Spring Security 라는 별도의 프레임워크에서 관련 기능을 제공하고 있다.

   <aside> 📌 Spring Security

   </aside>

   • Spring 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크.

   • 인증 과 권한 에 대한 부분을 Filter 흐름에 따라 처리함.

     Filter 는 Dispatcher Servlet 으로 가기 전에 적용되어 가장 먼저 URL 요청을 받는다.

   • 보안과 관련한 많은 옵션을 제공해주기에 개발자 입장에서 보안관련 로직을 작성하지 않아도 된다.

   [인증(Authorization) 과 인가(Authentication]

   • 인증 : 해당 사용자가 본인이 맞는지를 확인하는 절차
   • 인가 : 인증된 사용자가 요청한 자원에 접근 가능한지를 결정하는 절차

   

   • Spring Security는 기본적으로 인증 절차를 거친 후에 인가 절차를 진행함.
   • 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지 확인을 하게 된다.
   • Spring Security에서는 이러한 인증과 인가를 위해 Principal 을 아이디로, Credential 을 비밀번호로 사용하는 Credential 기반의 인증 방식을 사용한다.
     • Principal(접근 주체): 보호받는 Resource에 접근하는 대상
     • Credential(비밀번호): Resource에 접근하는 대상의 비밀번호

   <aside> 📌 Spring Security 주요 모듈

   </aside>

   

   [ SecurityContextHolder ]

   SecurityContextHolder는 보안 주체의 세부 정보를 포함하여 응용프래그램의 현재 보안 컨텍스트에 대한 세부 정보가 저장된다. SecurityContextHolder는 기본적으로 SecurityContextHolder.MODE_INHERITABLETHREADLOCAL 방법과SecurityContextHolder.MODE_THREADLOCAL 방법을 제공한다.

   [ SecurityContext ]