인프런 커뮤니티 질문&답변

엄엄

작성한 질문수

[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core

디버거 사용하기

로그인 엔드포인트 관련 질문

해결된 질문

작성

안녕하세요 코팩님 강의 정말 유용하게 듣고 있습니다 강의를 완강하고 난뒤 코드를 분석하고 있는 중 이상하다고 느낀 부분이 있어 질문드립니다

  @Post('login/email')
  @IsPublic()
  @UseGuards(BasicTokenGuard)
  postLoginEmail(
    @Headers('authorization') rawToken: string,
  ) {
    // email:password -> base64
    // asdkljoijzxlxck;vjaosi;dfjawe;lkrj -> email:password
    const token = this.authService.extractTokenFromHeader(rawToken, false);

    const credentials = this.authService.decodeBasicToken(token);

    return this.authService.loginWithEmail(credentials);
  }

이 부분에서 이미 Guards(BasicTokenGuard)가 사용자를 식별하고 심지어 인증까지 맡아 요청 부분에 user 정보까지 넣어둡니다. 그러면 이미 BasicTokenGuard가 로그인의 역할을 다 했는데 왜 한번 더 검증하는지 궁금해서 질문 남깁니다.

단순히 Guards의 예제를 위해서인지, 아니면 다른 이유가 있는지 설명해 주시면 정말 감사하겠습니다

javascript typescript rest-api nestjs backend

답변 2

코드팩토리

지식공유자

안녕하세요!

한번 더 검증은 어떤걸 말씀하시는걸까요?

@UseGuards(BasicTokenGuard) 외에 다른 하나 더 말씀하시는게 맞을까요?

아니면 extractTokenFromHeader 말씀하시는걸까요?

감사합니다!

엄엄

질문자

"한번 더 검증" 이라는 부분은 this.authService.loginWithEmail을 말하는겁니다

BasicTokenGuard에서는

        const user = await this.authService.authenticateWithEmailAndPassword({
            email,
            password,
        });

이런 방식으로 사용자를 검증하지만 loginWithEmail 부분에서도 authenticateWithEmailAndPassword을 호출해서 한번더 검증하는것을 알 수 있습니다.


  async loginWithEmail(user: Pick<UsersModel, "email" | "password">) {
    const existingUser = await this.authenticateWithEmailAndPassword(user);

    return this.loginUser(existingUser);
  }

저는 여기서 왜 authenticateWithEmailAndPassword을 한번 더 호출해서 BasicTokenGuard에서 충분하게 검증을 했음에도 불구하고 loginWithEmail에서 한번 더 사용자를 검증하는지 궁금하여 질문을 드립니다

코드팩토리

지식공유자

안녕하세요!

꼭 그럴 필요가 없긴 합니다.

레거시 코드라고 보시면 됩니다. (작성자분 말이 맞습니다)

감사합니다!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 엄엄님.

로그인 엔드포인트에서의 Guard 사용에 대해 궁금증이 있으시군요. BasicTokenGuard를 통해 이미 인증 및 사용자 식별이 완료되었음에도 불구하고 코드에서 다시 사용자 인증을 진행하는 부분이 헷갈릴 수 있습니다. 이 부분에 대해 설명드리겠습니다.

Guard의 역할: BasicTokenGuard는 주로 요청이 유효한 사용자로부터 온 것인지, 즉 인증된 요청인지 확인하는 역할을 합니다. Guard 내부에서 토큰을 검증하고, 인증이 완료되면 요청 객체에 사용자 정보를 추가하는 형태로 작동합니다.
서비스 계층의 추가 검증: 서비스 계층에서 토큰을 다시 검증하는 것은 응용 프로그램의 보안 강화를 위한 일반적인 패턴일 수 있습니다. 가드가 일차적으로 인증을 처리하지만 서비스 계층에서 추가적으로 검증하는 것은 보안상의 이중 체크로 볼 수 있습니다. 예를 들어, 토큰이 어떤 조건에서든 변조되었거나, 변조되지 않았음을 다시 한 번 확인함으로써 보안을 강화하려는 목적일 수 있습니다.
코드 확장 가능성: 보통 강의에서는 학습 효과를 높이기 위해 코드 구조를 명확히 하고 다양한 패턴을 보여주려고 노력합니다. 실제 운영 환경에서는 보안을 높이기 위해 이중 체크가 필요할 수도 있기 때문에 강의에서 이런 패턴을 소개할 수 있습니다.

기존의 Guard 패턴과 추가적인 인증 검증 계층에 대해 명확히 이해하시면, 시스템의 보안 및 구조적 설계에서 중요한 결정으로 작용할 수 있습니다.

관련 논의가 있었던 질문을 참고하시려면, guard와 controller 토큰 추출 / 디코드 중복 코드 관련 질문을 참조해 보세요. 여기서는 Guard와 중복 처리된 코드의 효율적인 활용법에 대해 설명하고 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

엄엄

작성한 질문수

전체 Q&A

질문하기