로그인 API의 목적은 단순하다.
ID/PW를 검증해서 “이 사람이 맞다”를 확인한 뒤,
Access Token과 Refresh Token을 발급해주는 것이다.
즉, 로그인은 “인증(Authentication)” 과정이다.
1. 로그인 요청 → 응답 전체 흐름
1. 클라이언트 → 로그인 요청
2. Controller → 요청 검증 후 Service 호출
3. Service → 유저 조회 및 비밀번호 검증
4. Repository → DB에서 유저 조회
5. PasswordEncoder → 비밀번호 일치 여부 확인
6. TokenProvider → JWT 토큰 생성
7. Service → 응답 DTO 조립
8. Controller → JSON 응답 반환
각 단계가 어떤 책임을 가지는지 이해하는 것이 중요하다.
2. 로그인 API 예시 (요청 데이터)
클라이언트 → 서버
POST /api/auth/login
Request Body
{
"email": "test@test.com",
"password": "1234"
}
클라이언트가 보내는 것은
“나는 이 계정의 소유자다”라는 증명 자료다.
3. Controller 단계
Controller의 역할은 교통정리다.
하는 일
- Request DTO 받기
- @Valid 등으로 형식 검증
- service.login(dto) 호출
- Service 결과를 Response DTO로 반환
Controller는 비즈니스 판단을 하지 않는다.
실제 로직은 Service에서 수행된다.
4. Service 단계 (핵심 로직)
Service는 로그인 비즈니스 로직의 중심이다.
1) 유저 조회
userRepository.findByEmail(email)
- 유저가 존재하지 않으면 예외 발생
- 존재하지 않는 계정 에러 반환
2) 비밀번호 검증
passwordEncoder.matches(rawPassword, encodedPassword)
- 원문 비밀번호와 암호화된 비밀번호 비교
- 일치하지 않으면 비밀번호 불일치 예외 발생
비밀번호는 반드시 암호화 상태로 DB에 저장되어야 한다.
3) 토큰 발급
- Access Token: 짧은 만료 시간
- Refresh Token: 긴 만료 시간 (재발급용)
예시 흐름
createAccessToken(userId, role)
createRefreshToken(userId)
Access Token에는 최소한의 식별 정보만 담는다.
예: userId, role, 만료시간
4) 응답 DTO 조립
Service는 최종적으로 다음을 조립한다.
- accessToken
- refreshToken
- 사용자 정보 (필요 최소한)
예시:
new LoginResponseDto(accessToken, refreshToken, userInfo)
5. Repository 단계
Repository는 단순하다.
- 이메일로 유저 조회
- User(Entity) 반환
Repository는 정책 판단을 하지 않는다.
조건에 맞는 데이터를 가져오는 역할만 한다.
6. TokenProvider(JWT) 역할
TokenProvider는 JWT 생성 전용 컴포넌트다.
하는 일:
- 유저 식별 정보(userId 등)
- 권한(role)
- 만료 시간(exp)
을 담아 서명된 토큰 문자열을 생성한다.
결과는 단순 문자열이다.
7. 최종 응답 (서버 → 클라이언트)
{
"accessToken": "eyJhbGciOiJIUzI1NiIs...",
"refreshToken": "eyJhbGciOiJIUzI1NiIs...",
"user": {
"id": 1,
"name": "혜린"
}
}
이제 클라이언트는
- Access Token을 헤더에 담아 API 요청
- 만료 시 Refresh Token으로 재발급 요청
을 수행한다.
8. 요청 → 응답 흐름 체크리스트
로그인 흐름을 추적할 때 확인할 포인트
- Controller: login(request) 받고 service.login(request) 호출
- Service: findByEmail()로 유저 조회
- Service: matches()로 비밀번호 검증
- Service: createAccessToken() / createRefreshToken() 호출
- Service: Response DTO 생성
- Controller: ResponseEntity로 JSON 응답 반환
9. 설계 관점에서 중요한 점
- Controller는 입구 담당
- Service는 인증 정책 실행
- Repository는 DB 조회
- TokenProvider는 토큰 생성 전용
각 역할을 분리해야
- 테스트가 쉬워지고
- 변경에 강해지며
- 재사용이 가능해진다.
최종 정리
로그인 API는 ID/PW 검증 → 토큰 발급 → 응답 반환의 흐름으로 동작한다.
Controller는 요청을 받고, Service는 인증 로직을 수행하며,
Repository는 유저를 조회하고, TokenProvider는 JWT를 생성한다.
로그인은 단순한 조회 API가 아니라 인증과 보안을 담당하는 핵심 진입점이다.
흐름을 단계별로 이해하면 보안, 토큰, 인증 구조가 자연스럽게 정리된다.
'백엔드 기초 재정비 > 스프링 계층 구조 이해' 카테고리의 다른 글
| Exception 종류 정리 (0) | 2026.03.04 |
|---|---|
| 트랜잭션 실패 사례와 롤백 필요성 정리 (0) | 2026.03.03 |
| 트랜잭션(Transaction) 개념과 주문 생성 예제 (0) | 2026.03.02 |
| DTO vs Entity 정리 (0) | 2026.02.26 |
| Controller / Service / Repository 역할 정리 (0) | 2026.02.25 |