개요

• Gateway 패턴이 적용된 MSA 환경에서 SCG(Spring Cloud Gateway)를 활용한 JWT 인증/인가 과정이 어떻게 적용되는지 시나리오별로 작성해보았습니다.
• 해당 Wiki 내용에 대해서 이해가 되지 않거나, 궁금한 내용이 있다면 User Service팀의 @jihoo, @yang-jaewon 또는 Infra 및 아키텍쳐 설계 담당자 @gnsals0904에게 질문해주세요!
• 잘못된 부분 건의, 지적 언제나 환영입니다

인증/인가 시나리오

1. 인증이 필요없는 요청

회원가입, 로그인, 일반 도서 조회, Eureka Health Check 등

1. Front -> Gateway

• 프론트에서 토큰 없이 API 요청 (ex. POST /auth/users/login)

2. Gateway

• 해당 경로는 인증을 통과하도록 설정해서 필터를 거치지 않도록 함
• 이후, 게이트웨이는 바로 서비스를 찌름

3. Gateway -> 특정 서비스

4. 특정 서비스

• 서비스 로직 수행 후 결과값 리턴

5. 서비스 -> Gateway

6. Gateway -> 프론트 -> 사용자

2. 로그인된 사용자만 가능한 요청 (인증이 필요한 요청)

마이페이지 조회, 주문 내역 조회 등

1. Front -> Gateway

• 이미 로그인한 사용자는 쿠키에 담긴 JWT값과 함께 http 요청을 보냄

2. Gateway

• Spring Cloud Gateway의 필터가 요청의 jwt가 유효한지 검증
  1. JWT가 존재하는가?
  2. 존재한다면, JWT가 유효한가?
  • 서명과 유효기간을 확인
• 이 경우에 두가지 분기로 처리
  1. 만약에 JWT가 없거나, 토큰이 손상, 만료되었다면 바로 401 처리
  2. 토큰이 유효하다면, JWT를 파싱하여 User ID(PK) 값을 획득하고 Header에 X-USER-ID, X-USER-ROLE 등을 붙여서 타 서비스에서 이용할 수 있도록 함

3. Gateway -> 특정 서비스

• X-USER-ID 값은 raw하게 읽을 수 있기 때문에 타 서비스에서는 키값을 몰라도 됨
• 대신 이 경우에는 외부에 네트워크가 노출되지 않도록 보안 설정이 중요함
  • Docker, Docker Network등을 이용해 외부로 포트가 노출되지 않도록 관리할 예정

4. 특정 서비스

• X-USER-ID 헤더로 전달된 사용자 ID와 Role을 이용해 서비스 로직 처리

5. 서비스 -> Gateway

6. Gateway -> 프론트 -> 사용자

3. 관리자 권한이 필요한 요청 (인가가 필요한 요청)

관리자 페이지 조회, 쿠폰 정책 발급 등

1. Front -> Gateway

• 위와 같음

2. Gateway

• 위와 같은데, 권한이 없다면 403 에러 응답

3. Gateway -> 특정 서비스

• 위와 같음

4. 특정 서비스

5. 서비스 -> Gateway

6. Gateway -> 프론트 -> 사용자

고민했던 부분

1. 왜 Gateway에서 굳이 JWT를 파싱해서 헤더로 값을 타 서비스에게 전달하나요? 각 서비스에서 직접 JWT를 파싱해도 되지 않나요?

• 그렇게 해도 되지만, 각 서비스에서 JWT 서명 키값을 알고있어야 합니다.
  • 물론, 이렇게 한다면 보안적으로 조금 더 안전하다는 장점이 있습니다.
• 각 서비스에서는 인증/인가에 관해 고민을 최소화하도록 하고 싶었습니다.
• 또한, 내부 통신 시 네트워크 오버헤드가 조금이라도 감소한다는 장점이 있습니다.