🐰 [flowbit] #14. JWT를 실제 인증 흐름에 연결하기

☘️ 1. 오늘 목표

이전 작업에서는 회원가입, 로그인, JWT 발급까지 구현했다.

로그인에 성공하면 accessToken을 발급받을 수 있었고, 인증의 첫 단계는 완성된 상태였다.

하지만 아직 한 가지 문제가 남아 있었다.

로그인에 성공했다는 사실을 서버는 알고 있었지만,
그 토큰이 실제 API 요청에서는 사용되지 않고 있었다.

즉 현재 상태는 이런 느낌이었다.

로그인 성공
→ JWT 발급
→ 끝

출입증은 발급했는데,
아직 문 앞 경비원이 없는 상태였다.

그래서 이번 작업 목표는 명확했다.

JWT를 실제 요청 인증 흐름에 연결한다.

---

☘️ 2. JWT를 왜 요청마다 다시 보내야 할까

처음에는 이런 생각이 들었다.

로그인 성공했는데 왜 또 토큰을 보내야 하지?

그 이유는 JWT 방식은 세션 방식과 다르기 때문이다.

	세션 방식:

		로그인
		→ 서버가 상태 기억

	JWT 방식:

		로그인
		→ 토큰 발급

		API 요청
		→ 토큰 같이 전달
		→ 서버가 매번 검증

즉 서버는 로그인 상태를 저장하지 않는다.

대신 클라이언트가 매 요청마다

Authorization: Bearer {accessToken}

형태로 출입증을 들고 온다.

---

☘️ 3. JWT Filter 추가

그래서 요청이 Controller까지 가기 전에
먼저 토큰을 검사하는 필터를 추가했다.

요청 흐름은 다음처럼 바뀌었다.

브라우저
↓
JWT Filter
↓
Controller
↓
Service

JWT Filter 내부 흐름은 다음과 같다.

Authorization 헤더 확인
↓
Bearer 제거
↓
JWT 추출
↓
토큰 검증
↓
사용자 조회
↓
SecurityContext 저장

JWT 검증 책임은 기존 JwtTokenProvider를 확장해서 처리했다.

public boolean validateToken(String token) {
    try {
        parseClaims(token);
        return true;
    } catch (Exception e) {
        return false;
    }
}

토큰을 읽기만 하는 것이 아니라,
서명과 만료시간까지 검증하도록 했다.

---

☘️ 4. Spring Security가 현재 사용자를 기억하는 방식

JWT Filter를 붙이고 나서도 한 가지 문제가 있었다.

인증은 되었는데

누가 로그인했는지

를 코드 안에서 쉽게 꺼낼 수 없었다.

Spring Security는 내부적으로 다음 공간에 현재 사용자를 저장한다.

SecurityContext

구조는 이런 느낌이다.

SecurityContext

┌────────────┐
│ userId=3  │
│ email=... │
└────────────┘

하지만 매번 다음처럼 꺼내는 건 너무 복잡했다.

SecurityContextHolder
        .getContext()
        .getAuthentication()

그래서 현재 로그인 사용자를 가져오는 전용 컴포넌트를 만들었다.

@Component
public class CurrentUserProvider {

    public Long getCurrentUserId() {

        Authentication authentication =
                SecurityContextHolder
                        .getContext()
                        .getAuthentication();

        CustomUserDetails userDetails =
                (CustomUserDetails)
                        authentication.getPrincipal();

        return userDetails
                .getUser()
                .getId();
    }
}

이제는 어디서든 다음처럼 사용할 수 있다.

Long userId = currentUserProvider.getCurrentUserId();

---

☘️ 5. 현재 로그인 사용자 조회 API 추가

JWT가 실제로 동작하는지 확인하기 위해
간단한 API도 추가했다.

GET /api/users/me

요청: Authorization: Bearer {accessToken}

응답: 3

토큰이 없으면: 403 Forbidden

토큰이 있으면: 현재 로그인 사용자 ID 반환

이 시점부터 JWT는 단순 문자열이 아니라
실제 사용자 정보를 연결하는 역할을 하기 시작했다.

---

☘️ 6. 예외 처리와 안정성 보강

인증 흐름을 붙이다 보니
기능 자체보다 실패 상황을 처리하는 것도 중요하다는 걸 느꼈다.

예를 들어 회원가입 로직은 처음에 이렇게 되어 있었다.

if (userRepository.existsByEmail(request.getEmail())) {
    throw new IllegalArgumentException("이미 사용 중인 이메일입니다.");
}

일반적인 경우에는 잘 동작한다.

하지만 동시에 같은 이메일 가입 요청이 들어오면 이런 상황이 가능했다.

요청 A
existsByEmail()
→ false

요청 B
existsByEmail()
→ false

요청 A
insert 성공

요청 B
insert
→ DB unique 충돌

그래서 최종적으로는 DB 제약 조건 예외까지 처리하도록 보완했다.

또 기존 GlobalExceptionHandler도 확장했다.

400 → 잘못된 요청
401 → 인증 실패
409 → 중복 요청
500 → 서버 내부 오류

기능이 정상 동작하는 것만큼,
실패했을 때 의미 있는 응답을 주는 것도 중요하다고 느꼈다.

---

☘️ 7. 이번 작업에서 정리된 인증 흐름

이번 작업 이후 Flowbit 인증 흐름은 다음처럼 정리됐다.

회원가입
→ BCrypt 인코딩
→ User 저장

로그인
→ JWT 발급

API 요청
→ Authorization 헤더 전달

JWT Filter
→ 토큰 검증

SecurityContext
→ 사용자 저장

CurrentUserProvider
→ 현재 사용자 조회

---

☘️ 8. 마무리

이전 작업에서는 JWT를 발급하는 단계까지만 구현했다.

이번에는 그 토큰을 실제 API 요청에 연결했다.

이제 Flowbit은 단순히 로그인 기능이 있는 상태가 아니라,

누가 요청했는지

를 알 수 있는 상태가 되었다.

이후에는 여기서 자연스럽게 다음 구조로 이어질 수 있다.

Task.createdBy
TaskEvent.actorId
WorkspaceMember.user
RBAC 권한 제어

오늘 작업을 한 문장으로 정리하면

발급된 JWT를 실제 인증 흐름에 연결하고, 현재 로그인 사용자와 예외 처리 구조까지 확장했다.