인프런 커뮤니티 질문&답변
작성한 질문수
인증 관련 질문
해결된 질문
작성
·
34
0
학습 관련 질문을 최대한 상세히 남겨주세요!
고민 과정도 같이 나열해주셔도 좋습니다.
먼저 유사한 질문이 있었는지 검색해보세요.
인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요 좋은 강의 잘 보고있습니다.
이와 같이 마이크로 서비스로 프로젝트가 구성되면, 유저 인증과 관련된 부분은 어떻게 처리되는지 궁금합니다.
일단 스스로 생각해본 바로는, 게시글/댓글 쓰기, 좋아요 API는 로그인 한 유저만 가능하다고 하면, 각각의 서비스에서 클라이언트의 요청을 받았을 때 해당 요청을 유저 API를 호출하여 인증을 하는 방식이 있을 것 같은데 이 방법은 각 서비스들이 유저 서비스를 알고 있어야 한다는 단점이 있을 것 같습니다..
위와 같은 상황에서의 실무에서 모범 사례나 정형화된 방법이 있을까요?
답변 2
1
leesh5000님, 안녕하세요!
일단 게시글/댓글/좋아요 서비스가 유저 서비스를 알고 있어도 되는지에 대해서 고민해보셔도 좋을 것 같습니다.
도메인에 대한 의존 관계로 보면, 게시글/댓글/좋아요 서비스는 유저를 참조하고 있습니다.
유저는 참조될 뿐이지, 게시글/댓글/좋아요 서비스들을 도메인들을 참조하진 않습니다.
즉, 게시글/댓글/좋아요 서비스가 유저 서비스를 참조한다고 하더라도, 의존성 단방향에 대한 원칙은 여전히 지켜질 수 있습니다.
따라서 이러한 구조도 어색함은 없고, 어차피 회원 정보를 검증하거나 API 응답 모델에 같이 내려줘야 한다면 오히려 필요한 상황입니다.
그래서 인증(Authentication)과 인가(Authorization)를 어디에서 어떤 방식으로 수행할 수 있을지도 궁금하실 것 같은데요, 이 또한 구성에 따라 다양할 수 있습니다.(참고로 인증과 인가는 구분하시면 좋습니다)
하나의 예시로서 이러한 방법으로 구성할 수도 있을 것 같습니다.
게시글/댓글/좋아요 서비스는 사용자를 인증하고 리소스에 대한 접근 권한을 확인하기 위해, 유저 서비스를 호출하면 됩니다.
유저 서비스는 각 서비스에게 사용자 정보, 권한 등의 "인증" 정보를 내려줍니다.
유저 서비스는 "인가"까지 처리하진 않습니다.
만약 유저 서비스가 리소스마다 접근 권한까지 검증한다면, 너무 과도한 책임을 가지게 됩니다.
각 리소스에 접근할 수 있는지 인가에 대한 책임은 게시글/댓글/좋아요 서비스가 가질 수 있는 것입니다.
유저 서비스 측에서는 이러한 기능을 쉽게 만들 수 있도록 모듈을 제공할 수도 있는 것이고요.
시큐리티를 사용하든지, 필터나 인터셉터를 사용하든지, AOP를 구현하는지 등 이것도 구현 방식은 다양할 수 있습니다.
또 다른 예시로, API 게이트웨이에서 사용자 인증을 하면 됩니다.
마이크로서비스로 향하는 모든 요청 흐름은 API 게이트웨이를 통하도록 합니다.
그리고 게이트웨이에서 인증된 토큰 정보를 요청에 포함하고, 마이크로서비스로 라우팅합니다.
여기에는 사용자 인증 정보도 포함할 수 있습니다.
각 마이크로서비스는 토큰을 검증 및 파싱하여 리소스 접근 권한을 검증하면 됩니다.
구현은 항상 다양할 수 있고, 로그인 방식 또는 인증/인가 요구사항마다 모두 달라질 수 있기 때문에 구체적인 모범 사례를 말씀드리긴 어렵지만,
위와 같이 의존성, 인증/인가에 대한 개념, 책임 분리 등에 대한 관점만 이해하고 있으면 적절한 인증 방식을 구성하실 수 있을 것 같습니다!
0
안녕하세요, 인프런 AI 인턴입니다. leesh5000님.
강의를 수강하시며 MSA(마이크로서비스 아키텍처) 환경에서의 유저 인증 전략에 대해 궁금하신 점이 생기셨군요. MSA에서는 개별 서비스 간의 인증이 중요한 과제이며, 다양한 방식이 존재합니다.
유저 인증 모범 사례
API Gateway 사용:
- API 게이트웨이를 통해 모든 클라이언트 요청이 통과하게 되며, 이 단계에서 인증 절차를 수행합니다. 로그인 후 토큰을 발급받고, API 요청 시 이 토큰을 헤더에 포함하여 인증합니다.
- API 게이트웨이가 인증 토큰을 검사하고, 유효할 경우 요청을 내부 서비스로 전달하는 구조입니다. 이를 통해 개별 서비스는 인증 관련 로직을 신경쓰지 않아도 됩니다.
- API 게이트웨이를 통해 모든 클라이언트 요청이 통과하게 되며, 이 단계에서 인증 절차를 수행합니다. 로그인 후 토큰을 발급받고, API 요청 시 이 토큰을 헤더에 포함하여 인증합니다.
OAuth2 / JWT 활용:
- OAuth2 및 JWT(JSON Web Token)를 통해 유저 인증을 처리할 수 있습니다. 사용자가 로그인하면 JWT를 발급받고, 이후 요청마다 JWT를 포함시켜 인증합니다.
- 각 서비스는 JWT의 유효성을 검사하여 사용자를 인증하며, 유효하지 않은 경우 접근을 제한합니다.
- OAuth2 및 JWT(JSON Web Token)를 통해 유저 인증을 처리할 수 있습니다. 사용자가 로그인하면 JWT를 발급받고, 이후 요청마다 JWT를 포함시켜 인증합니다.
세션 기반 인증:
- 상태를 관리하는 방법으로, 유저가 로그인 시 세션을 생성하고 이를 통해 인증을 구현할 수 있습니다. 하지만 MSA에서는 일반적으로 상태 관리의 복잡성이 증가하므로 토큰 기반 접근이 선호됩니다.
- 상태를 관리하는 방법으로, 유저가 로그인 시 세션을 생성하고 이를 통해 인증을 구현할 수 있습니다. 하지만 MSA에서는 일반적으로 상태 관리의 복잡성이 증가하므로 토큰 기반 접근이 선호됩니다.
Federated Identity 및 SSO(Single Sign-On):
- SSO를 통해 여러 서비스에 대해 한 번의 로그인으로 인증을 수행할 수 있도록 합니다. 이를 통해 사용자 경험을 향상시키고 인증의 일관성을 유지할 수 있습니다.
- SSO를 통해 여러 서비스에 대해 한 번의 로그인으로 인증을 수행할 수 있도록 합니다. 이를 통해 사용자 경험을 향상시키고 인증의 일관성을 유지할 수 있습니다.
관련된 유사한 질문에 대한 게시물을 통해 더 많은 정보를 참고할 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.