[데브코스] Spring Boot 인증·인가(Auth) (15강) - 글 작성 시 apiKey로 인증 전환

15강에서는 인증 방식이 결정적으로 바뀐다.
이제 더 이상 username/password로 인증하지 않고,
apiKey 하나로 사용자를 식별하도록 구조를 변경했다.

---

1️⃣ 기존 인증 방식의 문제 정리

❌ username / password 방식의 문제

이전 구조에서는 글 작성 시 이런 방식이었다.

POST /api/v1/posts?username=user1&password=1234

이 구조에는 여러 문제가 있었다.

문제 1️⃣ 사칭 가능성

• 누군가 다른 사용자의 username/password를 알게 되면
• 해당 사용자로 완벽하게 사칭 가능

문제 2️⃣ 매 요청마다 비밀번호 전달

• 모든 요청에 비밀번호가 포함됨
• 네트워크를 계속 타게 됨
• 보안상 매우 좋지 않음

문제 3️⃣ 클라이언트에 비밀번호 저장

• 모바일 앱 / 웹 브라우저에
• username/password를 저장해야 함
• 유출 시 피해가 매우 큼

👉 결론:

비밀번호를 인증 수단으로 쓰는 구조 자체가 위험하다.

---

2️⃣ 해결 전략: apiKey로 인증 전환

✔ apiKey 방식의 장점

• 비밀번호 ❌ → apiKey ⭕
• apiKey는 서버가 발급
• 노출되더라도 비밀번호보다 위험이 적음
• 필요 시 재발급 가능

👉 그래서 인증 정보를 이렇게 바꾼다.

이전: username + password
이후: apiKey

---

3️⃣ 15강에서 변경된 핵심 코드

📌 컨트롤러 변경 전

@NotBlank String username,
@NotBlank String password

Member actor = memberService.findByUsername(username).orElseThrow(...);
if (!actor.getPassword().equals(password)) throw ...

---

📌 컨트롤러 변경 후 (핵심)

@NotBlank @Size(min = 30, max = 50)
String apiKey

Member actor = memberService.findByApiKey(apiKey)
        .orElseThrow(() -> new ServiceException("401-1", "존재하지 않는 apiKey 입니다."));

✔ username/password 검증 로직 제거
✔ apiKey 하나로 사용자 식별

---

4️⃣ API 요청 방식 변화

🔴 변경 전

POST /api/v1/posts?username=user1&password=1234

🟢 변경 후

POST /api/v1/posts?apiKey=xxxxxxxx-xxxx-xxxx-xxxx

👉 이제 클라이언트는 apiKey만 저장하면 된다.

---

5️⃣ MemberRepository / Service 변경

MemberRepository

Optional<Member> findByApiKey(String apiKey);

MemberService

public Optional<Member> findByApiKey(String apiKey) {
    return memberRepository.findByApiKey(apiKey);
}

✔ apiKey로 회원 조회 가능
✔ 인증 로직이 훨씬 단순해짐

---

6️⃣ 테스트 코드도 apiKey 기준으로 수정

테스트에서 apiKey를 직접 가져옴

Member actor = memberService.findByUsername("user1").get();
String actorApiKey = actor.getApiKey();

요청 URL 변경

post("/api/v1/posts?apiKey=" + actorApiKey)

👉 실제 서비스 흐름과 테스트 흐름이 완전히 일치하게 됨

---

7️⃣ 여전히 남아있는 문제 (강의에서 짚은 포인트)

강사님이 명확하게 짚어준 부분 👇

⚠ apiKey도 완벽한 해결책은 아니다

• apiKey도 유출될 수 있음
• 하지만 username/password 유출보다는 훨씬 낫다
• 비밀번호는 변경이 번거롭고 치명적
• apiKey는 재발급 가능

👉 현 단계에서는 합리적인 선택

---

8️⃣ 왜 이 방식이 중요한가?

이 구조는 다음 단계로 이어진다.

• apiKey → Authorization Header
• apiKey → JWT
• apiKey → 세션 / 토큰 인증

즉,
“인증 정보를 URL/Body에 직접 넣지 않는 구조”로 가기 위한 중간 단계다.

---

9️⃣ 15강 핵심 요약

• username/password 기반 인증의 문제를 확인했다
• 매 요청마다 비밀번호를 보내는 구조는 위험하다
• apiKey를 인증 수단으로 전환했다
• 클라이언트에는 apiKey만 저장한다
• 테스트 코드와 실제 로직을 apiKey 기준으로 통일했다
• 보안과 구조 모두 이전보다 개선되었다

---

🔚 마무리

15강은 단순한 리팩토링이 아니다.
“인증 방식이 바뀌는 전환점”이다.

이제부터 인증의 중심은
👉 사람이 아는 비밀번호가 아니라
👉 서버가 발급한 신분증(apiKey) 이다.