[TIL] 삼성 시그니처: 인증/인가는 어디에 구현해야할까?

• ISSUE 1. 시큐리티는 어디에 걸어야할까
  • ❓문제상황
  • ❗해결방법
    • 1. Security란 무엇인가?
    • 2. Api Gateway에 security달기
    • 3. Member Service에 security달기
    • 4. 결론

ISSUE 1. 시큐리티는 어디에 걸어야할까

❓문제상황

• MSA환경에서 인증/인가를 처리할 곳을 정해야했다.
• 우리서비스의 경우, OAuth는 사용하지않고 JWT를 활용한 서비스 자체의 로그인으로 인증을 진행하려한다.
• 그렇다면 모든 API가 들어오는 Api Gateway에 인증절차를 두어야할까 아니면 유저의 정보를 다루는 Member service 에 두어야할까 고민이 되었다.

❗해결방법

1. Security란 무엇인가?

• Spring MVC와 관계없이 Filter로 인증/인가를 체크할 수 있는 프레임워크이다.
• 인증객체(UserDetail)를 생성하여 백엔드 서버 내에서 인증된 유저임을 보장해준다.
• 우리 서비스의 경우에 UserDetail을 사용하려면 모든 서비스에 security를 dependency해야한다.
  • 인증/인가는 api gateway에서만 진행되는데 중복적으로 filter를 타는게 맞을까..?

2. Api Gateway에 security달기

• Api Gateway는 리버스 프록시 역할을 할뿐 Web server가 아니다.
• jwt token발급을 api gateway에서 진행시 api gateway가 jwt토큰을 생성하고 유저 정보를 조회하기 위해서는 db에 접근해야한다.
• Api Gateway에는 JWT토큰이 유효한지 확인하는 필터를 추가하여 인증/인가에대한 역할만 수행하도록 하려고한다.

3. Member Service에 security달기

• Member service의 메소드
  • 회원가입 → token없음
  • 로그인 → token 없음, jwt만듦
  • 로그아웃 → token 있음, jwt해제
  • refresh token 재발급 → token있음, jwt새로만듦
• 위와같은 로직밖에 없다면 굳이 security를 달 이유가 있을까?
  • api인증/인가에 경우에는 apigateway에서 판단하게된다. member service에 도달하기전 api gateway에서 확인 후 member service에보내기 때문에 filter를 탈 이유가 없다.
• 그렇다면 member service는 jwt토큰을 생성하고 해제하는 역할만 하면 된다.

4. 결론

• Api Gateway : filter추가
  • jwt token 유효한지 체크 Filter
  • 유효하다면 request api에 Http head에 memberId추가하여 보내기
  • 유효하지 않으면 401
• Member service : jwt token 생성역할
  • 로그인, refresh token 재발급
    • jwt provider로 access token, refresh token 생성하여 클라이언트에게 전달
  • 로그아웃
    • black list를 사용하여 refresh token 탈취 방지

☝ security의 필터들을 분해하여 각각의 서비스에 적용하는 식으로 구현예정