scant

scant

Be kindly

마이크로서비스 인증/인가 패턴

Updated:

마이크로서비스 인증/인가 패턴

여러 개의 마이크로서비스에 대한 인증/인가 등 접근 제어는 어떻게 구현해야 할까? 각 서비스가 모두 인증/인가를 중복으로 구현한다면 비효율적이다. 따라서 마이크로서비스 인증/인가를 처리하기 위해서는 일반적으로 다음과 같은 패턴들을 활용한다.

  • 중앙 집중 식 세션 관리

    기존 모노리스 방식에서 가장 많이 사용했던 방식은 서버 세션에 사용자의 로그인 정보 및 권한 정보를 저장하고 이를 통해 어플리케이션에 인증/인가를 판단하는 것이다. 그렇지만 마이크로서비스는 사용량에 따라 수시로 수평 확장할 수 있고 로드 밸런싱이 되기 때문에 세션 데이터가 손실될 수 있다. 따라서 마이크로비스는 각자의 서비스에 세션을 저장하지 않고 공유 저장소에 세션을 저장하고 모든 서비스가 동일한 사용자 데이터를 얻게 한다. 보통 세션 저장소로 레디스(Redis), 맴캐쉬드(Memcached)를 사용한다.

  • 클라이언트 토큰

    세션은 서버의 중앙에 저장되고 토큰은 사용자의 브라우저에 저장된다. 토큰은 사용자이 신원정보를 가지고 있고 서버로 요청을 보낼 때 전송되기 때문에 서버에서 인가 처리를 할 수 있다.JWT(Json Web Token)은 토큰 형식을 정의하고 암호화 하며 다양한 언어에 라이브러리를 제공하는 공개 표준(RFC 7519)이다. 토큰을 통한 사용자 인증 흐름은 다음 다이어그램과 같다.

  • 브라우저가 서버에 로그인이름과 패스워드로 인증을 요청한다.
  • 서버는 인증 후 토큰을 생성하고 브라우저에 토큰에 사용자 정보의 인증/인가 정보를 포함에 전송한다.
  • 브라우저는 서버 리소스 요청 시 토큰을 같이 보낸다. 서버의 서비스는 토큰 정보를 확인후 자원 접근을 허가한다.

클라이언트 토큰 흐름도

  • API 게이트웨이를 사용한 클라이언트 토큰

    사용자 인증 프로세스는 토큰 인증 프로세스와 유사하다. 차이점은 API 게이트웨이가 외부 요청의 입구로 추가된다는 것이다. 또한 인증/인가에 처리를 위한 별도의 전담서비스를 만들어서 다른 서비스의 인증/인가 처리를 위임 시킬 수 있다. 이런 서비스 Auth서비스라 하는데 API 게이트웨이와 연동해서 인증 인가를 처리한다. Auth서비스를 사용하면 각각의 리소스 서비스가 자체적으로 인증 인가를 처리하지 않고 순수 업무처리에 집중할 수 있다.

아래 그림을 통해 동작 메커니즘을 살펴보면

  1. 클라이언트가 리소스 서비스에 접근을 요청하면 API 게이트웨이는 Auth서비스에게 포워딩한다.
  2. Auth 서비스는 해당 요청이 인증된 사용자인지(인증) 해당 리소스 접근 권한이 있는지 (인가)확인하고 모두 가능하다면 리소스에 접근 가능한 증명서인 토큰을 발급한다.
  3. 클라이언트는 다시 액세스 토큰을 활용하여 접근을 요청한다.
  4. 그럼 각각의 리소스 서비스는 이런 요청이 액세스 토큰을 포함하고 있는지 판단하여 리소스를 허용한다

API게이트웨이와 인증서비스를 활용한 클라이언트 토큰 흐름도

You May Also Enjoy