@AuthenticationPrincipal 어노테이션 사용에 대하여

[unikal1]

상기된 어노테이션은, spring security 에서 인증 후 CustomUserDetails 를 매핑하는 어노테이션입니다. 즉, 컨트롤러에서 이를 통해 CustomUserDetails 를 매개변수로 받을 수 있습니다. 현재 저희 프로젝트는 MemberDetails 를 사용하고 있으며 이 안에는 Member 엔티티가 존재합니다.

고민되는게,

1. 결국 반환되는 MemberDetails 에서 id 등을 알기 위해 Member 를 호출할텐데, 이런 엔티티를 컨트롤러에서 직접 다루는게 괜찮을까?

2. 만약 해당 엔티티에 lazy loading 객체가 존재한다면, 이를 호출할 때 LazyInitializationException 을 뱉을 텐데, 괜찮나?
   2-1. 이에 대한 해결 방법으로써, member 엔티티에 다른 연관관계를 두지 않던지, 혹은 연관 관계인 객체를 호출하지 않으면 되긴 하지만, 만약 필요하다면 그 해결 방법은?

3. 결국, 찾아본 바에 의하면 UserDetailsService 의 loadUserByUsername의 반환 객체를 반환한다고 하는데 이는 db에서 해당 유저를 조회하는 쿼리를 발생시키게 됨. 이럴꺼면 차라리 jwt 에서 추출한 id 만 가져오고, 이를 통해 검색 등을 하면 되지 않나?

기존에는 contextHolder 에서 유저 정보를 가져왔으나 해당 방식 자체는 굉장히 좋아 보이긴 합니다. 다만, 상기 명시된 항목에 대해 의견 있을까요?

[s0o0bn]

음 아 그렇네요. 리뷰할 때 이 부분을 미처 고려를 못 했는데,
어차피 MemberDetails에서는 로그인 시 계정 정보 검증을 위한 ID/PW, 토큰 발급에 사용하기 위한 PK 값만 필요할텐데
그러면 해당 클래스에서 Member 자체를 갖고 있는게 아니라 위 3가지 데이터만 갖고 있도록 하는 건 어떨까요?

생각해보니 저는 이전 프로젝트에서는 그런 식으로 했던 기억이 있습니다.
말씀하신 바와 같이 굳이 인증을 위한 클래스에서 이에 관련된 데이터 외의 Member의 데이터(이름, 생일 등등)까지 모두 갖고 있을 필요는 없어 보입니다.

3번 항목에서 설명하신 내용의 의미를 정확하게 파악하지 못 했습니다.
로그인 시 loadUserByUsername으로 인해 유저 조회 쿼리가 발생하는 것 말씀하시는 걸까요?

[unikal1]

음, 살짝 말하는 바가 다른 것 같습니다.
일단 userDetails 의 구현 방식에 대한 것은 잠시 미뤄두고, 단순히 해당 어노테이션을 이용할 것인가에 대한 의견을 구한 것입니다. 사실 단점 밖에 안보이긴 합니다만, 기존에 어떻게 사용하였는지 궁금해서요.

해당 어노테이션은 보통 다음과 같이 사용됩니다.

@postMapping("/test")
public Response<?> someApi(@AuthenticationPrincipal MemberDetails memberDetails) {
    return Response.ok(memberDetails.getMember().getId();
}

이는 즉, 클라이언트로부터 받은 데이터를 가지고 loadUserByUsername 메서드를 통해 반환받은 CustomUserDetails 를 사용하도록 도와줍니다. 다만, 현재 저희 로직 상 해당 메서드는 MemberRepository 를 통하여 유저 정보를 가져오기 때문에, 결국 이러한 조회 쿼리가 계속 발생할 수 밖에 없다는 점을 말씀드리고 싶습니다.

기본적으로 SecurityContextHolder 에서 가져오는 데이터는 JWT 에서 추출한 사용자 정보(가령, ID) 정도만 저장되고, 따라서 컨트롤러에서 해당 id 를 받아서 이를 통해 여러 비지니스 로직을 수행합니다.
그러나 해당 어노테이션은, 여기서 한발 더 나아가 DB에서 조회한 Member 객체가 포함된 MemberDetails 를 컨트롤러 단계에서 다룰 수 있게 해준다는 것입니다.

즉, 모든 요청에 대하여, 만약 해당 방식읗로 MemberDetails 를 매개변수로 받는 컨트롤러 메서드는 필연적으로 DB의 조회가 일어나게 되는데, 과연 이게 "코드의 간결함"을 사유로 용납될 수 있는지에 대한 의견입니다.

[s0o0bn]

아 이해했습니다.

엇 그런데 그동안 제가 알기로는 @AuthenticationPrincipal은 JwtAuthenticationFilter에서 security context에 저장한 값(현재 저희 코드 기준 UsernamePasswordAuthenticationToken)에서 principal 값을 전달하는 것으로 알고 있습니다. 그래서 이름도 저런거구요.
즉, 현재 상혁님이 구현해주신 아래 코드에 의하면 Long 타입의 id를 받는거죠.

Long id = jwtData.getId();
UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(
            id, null, List.of()
);
SecurityContextHolder.getContext().setAuthentication(authentication);

그리고 controller에서는 아래와 같이 사용하게 됩니다.

@postMapping("/test")
public Response<?> someApi(@AuthenticationPrincipal Long userId) {
    return Response.ok(userId);
}

그래서 사실상 저기서 principal에 MemberDetails 객체를 담는게 아니라면 상혁님이 우려하시는 상황은 발생하지 않을 것으로 보입니다.

저 역시 이전 프로젝트에서 API 마다 사용자 PK 값만 필요하다면 위 방식대로 id 값만 담고 있도록 하고,
특정 프로젝트에선 role이 함께 필요해서 별도의 DTO를 두어, 그걸 principal에 담아 사용했습니다.

일단 저는 해당 어노테이션과 관련해서 이렇게 알고 있었는데, 혹시 잘못된 내용이 있다면 말씀해주세요!

[unikal1]

확인해보니까 맞네요 😢 기존엔 contextholder에서만 가져와서, 해당 어노테이션이 있다는 것을 알고 검색해봤는데, 제가 단단히 착각한거 같습니다.

하나 배워갑니다... 심지어 userdetails가 반환된다 한들, 이런 경우는 보통 securityContextHolder 에 해당 객체 자체가 저장되어 반환되는게 맞는데 왜 매번 DB 조회가 일어난다고 착각한건지, 저도 제가 이해가 안가네요...