백엔드 스터디 Day 6: 로그인과 권한 흐름을 코드에서 읽기

인증 Authentication: 너 누구야?
인가 Authorization: 너 이거 해도 돼?

PATCH /api/posts/10
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{
  "title": "수정된 제목",

1. 인증: 토큰을 해석했더니 userId=3인 사용자가 보낸 요청인가?
2. 인가: userId=3이 postId=10을 수정할 권한이 있는가?

로그인 API: 사용자 신원을 확인하고 토큰을 발급한다
JWT 필터: 요청마다 토큰을 읽어서 현재 사용자 정보를 만든다
Controller: 현재 사용자 정보를 받아 Service에 넘긴다
Service: 이 사용자가 이 기능을 실행해도 되는지 확인한다

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/auth")
public class AuthController {

    private final AuthService authService;

    @PostMapping("/login")
    public ResponseEntity<LoginResponse> login(@Valid @RequestBody LoginRequest request) {
        LoginResponse response = authService.login(request);
        return ResponseEntity.ok(response);
    }
}

public record LoginRequest(
        @NotBlank String email,
        @NotBlank String password
) {
}

public record LoginResponse(
        String accessToken,
        String tokenType,
        UserSummary user
) {
}

프론트엔드는 email/password를 보낸다.
백엔드는 accessToken과 사용자 요약 정보를 돌려준다.
프론트엔드는 이후 요청에 Authorization 헤더를 붙인다.

const response = await fetch("/api/auth/login", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email, password }),
});

const data = await response.json();
localStorage.setItem("accessToken", data.accessToken);

await fetch("/api/posts", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${token}`,
  },
  body: JSON.stringify({ title, content }),
});

{
  "accessToken": "...",
  "tokenType": "Bearer"
}

// 위험: 백엔드 응답에는 token이 없는데 token을 읽고 있다
localStorage.setItem("token", data.token);

@Service
@RequiredArgsConstructor
public class AuthService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;
    private final JwtTokenProvider jwtTokenProvider;

    @Transactional(readOnly = true)
    public LoginResponse login(LoginRequest request) {
        User user = userRepository.findByEmail(request.email())
                .orElseThrow(() -> new UnauthorizedException("이메일 또는 비밀번호가 올바르지 않습니다."));

1. 이메일로 사용자를 찾는다
2. 입력 비밀번호와 저장된 비밀번호 해시를 비교한다
3. 토큰을 발급한다

// 위험: 평문 문자열 비교처럼 보인다
if (!request.password().equals(user.getPassword())) {
    throw new UnauthorizedException("로그인 실패");
}

passwordEncoder.matches(request.password(), user.getPassword())

회원가입 때 비밀번호를 encode해서 저장하는가?
로그인 때 matches로 비교하는가?
응답에 password/passwordHash가 포함되지 않는가?
로그인 실패 메시지가 이메일 존재 여부를 과하게 노출하지 않는가?

return new LoginResponse(user.getId(), user.getEmail(), user.getPassword(), token);

로그인 성공
→ 백엔드가 accessToken 발급
→ 프론트엔드가 토큰 저장
→ 다음 요청부터 Authorization 헤더에 토큰 첨부
→ 백엔드 필터가 토큰 검증
→ 현재 사용자 정보를 SecurityContext에 넣음
→ Controller/Service가 현재 사용자 기준으로 동작

@Component
public class JwtTokenProvider {

    private final SecretKey secretKey;
    private final Duration accessTokenValidity = Duration.ofHours(2);

    public String createAccessToken(Long userId, Role role) {
        Instant now = Instant.now();
        return Jwts.builder()
                .subject(String.valueOf(userId))
                .claim("role", role

subject: 보통 userId
claim role: 사용자 권한
issuedAt: 발급 시각
expiration: 만료 시각
signWith: 위조 방지를 위한 서명

토큰에 필요한 최소 정보만 들어가는가?
비밀번호, 주민번호, 전화번호 같은 민감 정보가 들어가지 않는가?
만료 시간이 있는가?
서명 키가 코드에 하드코딩되어 있지 않은가?
토큰 검증 실패 시 요청이 차단되는가?

// 위험: secret이 코드에 직접 들어 있다
private static final String SECRET = "my-super-secret-key";

public JwtTokenProvider(@Value("${jwt.secret}") String secret) {
    this.secretKey = Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8));
}

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;
    private final CustomUserDetailsService userDetailsService;

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain
    ) throws ServletException, IOException {
        String token = resolveToken(request);

        if (token != null && jwtTokenProvider.validateToken(token)) 

Authorization 헤더를 읽는다.
Bearer 접두사를 제거해서 토큰만 꺼낸다.
토큰이 유효하면 userId를 꺼낸다.
userId로 사용자 정보를 로드한다.
Spring Security의 현재 인증 정보에 사용자 정보를 넣는다.
다음 필터/Controller로 요청을 넘긴다.

try {
    // token parse
} catch (Exception e) {
    // 아무것도 안 함
}
filterChain.doFilter(request, response);

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .csrf(AbstractHttpConfigurer::disable)
                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(HttpMethod.  

로그인/회원가입은 누구나 접근 가능
게시글 조회는 누구나 접근 가능
관리자 API는 ADMIN만 가능
나머지는 로그인 필요
JWT 필터는 Spring Security 인증 필터 앞에 둔다

.anyRequest().permitAll()

프론트엔드 보호: 로그인 안 하면 화면을 안 보여준다
백엔드 보호: 로그인 안 하면 API가 데이터를 안 준다

@PostMapping("/posts")
public ResponseEntity<PostResponse> createPost(
        @Valid @RequestBody CreatePostRequest request,
        @AuthenticationPrincipal CustomUserPrincipal principal
) {
    PostResponse response = postService.createPost(request, principal.getUserId());
    return ResponseEntity.status(HttpStatus.CREATED).body(response);
}

public record CreatePostRequest(
        Long userId,
        String title,
        String content
) {
}

{
  "userId": 999,
  "title": "남의 계정으로 작성",
  "content": "..."
}

현재 사용자 ID는 토큰/세션에서 가져온다.
클라이언트가 보낸 userId를 신뢰하지 않는다.

public PostResponse createPost(CreatePostRequest request, Long currentUserId) {
    User author = userRepository.findById(currentUserId)
            .orElseThrow(() -> new NotFoundException("사용자를 찾을 수 없습니다."));

    Post post = Post.create(request.title(), request.content(), author);
    return PostResponse.from(postRepository.save(post));
}

@Transactional
public PostResponse updatePost(Long postId, UpdatePostRequest request, Long currentUserId) {
    Post post = postRepository.findById(postId)
            .orElseThrow(() -> new NotFoundException("게시글을 찾을 수 없습니다."));

    if (!post.isWrittenBy(currentUserId)) {
        throw new ForbiddenException("게시글을 수정할 권한이 없습니다.");
    }

    post.update(request.title(), request.

postId로 게시글을 찾는다.
없으면 404.
현재 사용자가 작성자인지 확인한다.
작성자가 아니면 403.
권한이 있으면 내용을 수정한다.

public boolean isWrittenBy(Long userId) {
    return this.author.getId().equals(userId);
}

if (!post.isWrittenBy(currentUserId) && !currentUserRole.isAdmin()) {
    throw new ForbiddenException("게시글을 수정할 권한이 없습니다.");
}

@Transactional
public PostResponse updatePost(Long postId, UpdatePostRequest request) {
    Post post = postRepository.findById(postId)
            .orElseThrow(() -> new NotFoundException("게시글을 찾을 수 없습니다."));

    post.update(request.title(), request.content());
    return PostResponse.from(post);
}

이 기능은 누구나 해도 되는가?
로그인만 하면 되는가?
본인 리소스만 가능한가?
관리자만 가능한가?
조직/팀/프로젝트 멤버만 가능한가?
그 규칙이 코드에서 실제 데이터 조회 후 확인되는가?

{
  "code": "UNAUTHORIZED",
  "message": "로그인이 필요합니다."
}

{
  "code": "FORBIDDEN",
  "message": "게시글을 수정할 권한이 없습니다."
}

401 → 로그인 페이지로 보낸다
403 → 권한 없음 메시지를 보여준다
404 → 존재하지 않는 글이라고 알려준다

throw new RuntimeException("권한 없음");

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(UnauthorizedException.class)
    public ResponseEntity<ErrorResponse> handleUnauthorized(UnauthorizedException e) {
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
                .body(ErrorResponse.of("UNAUTHORIZED", e.getMessage()));
    }

    @ExceptionHandler(ForbiddenException.class)
    public ResponseEntity  e 

@Transactional
public SignupResponse signup(SignupRequest request) {
    if (userRepository.existsByEmail(request.email())) {
        throw new ConflictException("이미 사용 중인 이메일입니다.");
    }

    String encodedPassword = passwordEncoder.encode(request.password());

    User user = User.create(
            request.email(),
            encodedPassword,
            request.nickname(),

이메일 중복을 확인하는가?
비밀번호를 encode해서 저장하는가?
기본 role이 과하게 높지 않은가?
응답에 password가 빠져 있는가?

User user = User.create(
        request.email(),
        request.password(),
        request.nickname(),
        Role.ADMIN
);

@Column(nullable = false, unique = true)
private String email;

create unique index uk_users_email on users(email);

public enum Role {
    USER,
    ADMIN
}

public Collection<? extends GrantedAuthority> getAuthorities() {
    return List.of(new SimpleGrantedAuthority("ROLE_" + role.name()));
}

.requestMatchers("/api/admin/**").hasRole("ADMIN")

Role enum 값은 무엇인가?
GrantedAuthority로 바뀔 때 접두사가 붙는가?
SecurityConfig의 hasRole/hasAuthority와 일치하는가?
JWT claim에 들어가는 role 문자열과 일치하는가?
프론트엔드가 role 값을 사용할 때 같은 이름을 기대하는가?

{
  user.role === "ADMIN" && <AdminMenu />;
}

access token: 짧게 살아 있는 API 출입증
refresh token: access token을 다시 발급받기 위한 긴 수명의 토큰

로그인 성공 시 access token과 refresh token을 둘 다 발급하는가?
refresh token은 어디에 저장하는가? DB? Redis? HttpOnly cookie?
access token 재발급 API가 있는가?
로그아웃/탈퇴 시 refresh token을 무효화하는가?

[ ] 회원가입 때 비밀번호를 PasswordEncoder로 encode해서 저장한다.
[ ] 로그인 때 PasswordEncoder.matches로 비교한다.
[ ] 로그인 실패 메시지가 이메일 존재 여부를 과하게 노출하지 않는다.
[ ] 응답 DTO에 password/passwordHash가 없다.
[ ] 이메일/닉네임 중복은 Service와 DB 제약으로 함께 막는다.
[ ] 기본 role이 USER처럼 최소 권한이다.

[ ] Authorization: Bearer <token> 형식을 일관되게 사용한다.
[ ] 토큰에 userId/role 같은 최소 정보만 넣는다.
[ ] 토큰에 비밀번호/전화번호/민감 개인정보를 넣지 않는다.
[ ] 만료 시간이 있다.
[ ] secret key가 코드에 하드코딩되어 있지 않다.
[ ] 잘못된/만료된 토큰은 보호 API에서 401로 처리된다.

[ ] SecurityConfig에서 공개 API와 보호 API가 분리되어 있다.
[ ] anyRequest().permitAll()이 운영 코드에 남아 있지 않다.
[ ] 관리자 API는 role 기반으로 막혀 있다.
[ ] 프론트엔드 라우트 보호만 믿지 않고 백엔드 API도 보호한다.

[ ] 현재 사용자 ID를 request body에서 받지 않는다.
[ ] @AuthenticationPrincipal 또는 SecurityContext에서 현재 사용자를 얻는다.
[ ] 작성/수정/삭제 기능은 Service에서 소유권/권한을 확인한다.
[ ] 로그인만 필요한 기능과 본인 리소스만 가능한 기능을 구분한다.
[ ] 권한 없음은 403, 인증 없음은 401로 구분한다.

POST /api/auth/login

{
  "email": "jing@example.com",
  "password": "password123"
}

{
  "accessToken": "eyJhbGciOi...",
  "tokenType": "Bearer",
  "user": {
    "id": 3,
    "email": "jing@example.com",
    "nickname": "진규",
    "role": "USER"
  }
}

POST /api/posts
Authorization: Bearer eyJhbGciOi...

{
  "title": "첫 글",
  "content": "내용"
}

Authorization 헤더 읽기
→ 토큰 검증
→ userId=3 추출
→ UserDetails 로드
→ SecurityContext에 인증 정보 저장

@PostMapping("/posts")
public ResponseEntity<PostResponse> createPost(
        @Valid @RequestBody CreatePostRequest request,
        @AuthenticationPrincipal CustomUserPrincipal principal
) {
    return ResponseEntity.status(HttpStatus.CREATED)
            .body(postService.createPost(request, principal.getUserId()));
}

@Transactional
public PostResponse createPost(CreatePostRequest request, Long currentUserId) {
    User author = userRepository.findById(currentUserId)
            .orElseThrow(() -> new NotFoundException("사용자를 찾을 수 없습니다."));

    Post post = Post.create(request.title(), request.content(), author);
    return PostResponse.from(postRepository.save(post));
}

@Transactional
public PostResponse updatePost(Long postId, UpdatePostRequest request, Long currentUserId) {
    Post post = postRepository.findById(postId)
            .orElseThrow(() -> new NotFoundException("게시글을 찾을 수 없습니다."));

    if (!post.isWrittenBy(currentUserId)) {
        throw new ForbiddenException("게시글을 수정할 권한이 없습니다.");
    }

    post.update(request.title(), request.

수정 버튼을 눌렀는데 403이 나온다.
로그인했는데 내 프로필 API가 401을 반환한다.
관리자 계정인데 관리자 메뉴 API가 403을 반환한다.
게시글 작성자는 나인데 수정 권한이 없다고 나온다.

1. 프론트엔드가 Authorization 헤더를 실제로 보내는가?
2. 헤더 형식이 Bearer <token>인가?
3. 토큰이 만료되지 않았는가?
4. 백엔드 JWT 필터가 userId/role을 제대로 꺼내는가?
5. Controller가 principal을 제대로 받고 있는가?
6. Service가 currentUserId와 리소스 소유자를 올바르게 비교하는가?
7. role 문자열이 SecurityConfig와 일치하는가?
8. 에러 응답이 401/403/404 중 무엇인가?

인증은 “너 누구야?”다.
인가는 “너 이거 해도 돼?”다.
로그인 API는 토큰을 발급한다.
JWT 필터는 매 요청마다 현재 사용자를 만든다.
SecurityConfig는 어떤 API가 열려 있는지 정한다.
Controller는 현재 사용자 정보를 Service에 넘긴다.
Service는 리소스 소유권과 기능 권한을 확인한다.

프론트엔드 로그인 요청
→ AuthController
→ AuthService
→ PasswordEncoder
→ JwtTokenProvider
→ 프론트엔드 Authorization 헤더
→ JwtAuthenticationFilter
→ SecurityContext
→ Controller의 현재 사용자
→ Service의 권한 확인