[데브코스] Spring Boot 인증·인가(Auth) 기초

이번 글에서는 기존 GitHub 프로젝트를 클론해서 가져오고,내 GitHub 레포지토리로 다시 연결하는 방법을 정리합니다.📌 수업 1~3강에서 다룬 핵심 내용 정리용 글입니다.우선 강사님이 제공한 GitHub 저장소를 내 로컬 PC로 가져와야 합니다.이 명령어를 실행

이번 강의부터는 REST API 구현을 넘어 인증(Authentication)과 인가(Authorization) 를 본격적으로 다루기 시작했다.기존 구조의 가장 큰 문제점부터 짚고, 이를 해결하기 위한 첫 단계로 회원(Member) 개념을 도입한다.현재 프로젝트 상태에

4강에서 회원(Member)을 도입했다면,이번 5강에서는 글(Post)과 댓글(PostComment)에 작성자(author)를 실제로 연결하는 작업을 진행했다.이 작업은 이후 “본인만 수정/삭제 가능”한 인가(Authorization) 구현의 핵심 기반이 된다.기존 구

이번 강의에서는 응답 DTO에 작성자 정보를 명시적으로 포함하도록 구조를 변경했다.엔티티에 author(Member)가 연결된 상태에서,API 응답에서도 “누가 작성했는지”를 명확하게 내려주기 위한 작업이다.이전 단계까지는 다음과 같은 한계가 있었다.글과 댓글에는 작성

이번 강의에서는 DTO 응답 스펙이 바뀌면 테스트 코드도 반드시 함께 수정해야 한다는 점을 다뤘다.테스트는 단순히 “돌아가나 확인”이 아니라, API 응답 스펙(계약)을 고정하는 역할을 한다.6강에서 PostDto, PostCommentDto에 작성자 정보가 추가되었다

이번 강의의 핵심은 한 문장으로 정리된다.DTO에는 “꼭 필요한 데이터만” 담아라. (최소공개원칙, Principle of Least Privilege)DTO는 “내부 엔티티 구조를 그대로 보여주는 것”이 아니라,클라이언트가 필요한 정보만 정확히 전달하기 위한 응답 스

이번 9강에서는 글 작성 API에서 작성자(user1 고정) 방식 대신,클라이언트가 username을 전달하면 그 값으로 작성자를 찾도록 변경했다.그리고 @NotBlank, @Size 같은 파라미터 검증이 실패할 때 발생하는 예외인ConstraintViolationEx

9강에서 글 작성 시 username을 파라미터로 입력받아 작성자를 결정하도록 만들었는데,이 방식에는 큰 문제가 있었다.사칭이 가능하다.user2가 요청 파라미터에 username=user1만 넣으면 user1인 척 글을 작성할 수 있다.이번 10강에서는 이 문제를 막

이번 강의에서 내가 헷갈렸던 핵심은 이거였다.“에러가 나면 왜 어떤 때는 JSON이 아니라 404(정적 리소스)처럼 나오지?”“@ResponseBody를 붙였다가 뺐다는데, 그게 왜 중요하지?”“GlobalExceptionHandler가 있는데 왜 ServiceExce

이번 강의(12강)를 보면서 가장 헷갈렸던 건 이거였다.@ControllerAdvice 붙이면 뭐가 달라지는 거지?@Controller랑 무슨 차이야?RestController랑 뭐가 다른데?IllegalArgumentException 쓰면 안 되나?왜 굳이 Servi

13강은 새로운 코드를 많이 치는 강의가 아니었다.대신 지금까지 우리가 왜 이렇게 복잡한 구조를 만들었는지를 정리해주는 강의였다.이 강의를 한 문장으로 요약하면 이거다.스프링부트는 사용자를 기억하지 못한다.강의에서 가장 인상 깊었던 표현이 있었다.스프링부트는 금붕어다.

14강에서는 인증 구조가 한 단계 바뀌기 시작한다.지금까지는 모든 요청에 username/password를 직접 실어서 인증했지만,이제 API KEY를 인증 정보로 사용하기 위한 준비 단계에 들어간다.13강에서 정리했던 문제를 다시 보면 이렇다.스프링부트는 요청을 기억

15강에서는 인증 방식이 결정적으로 바뀐다.이제 더 이상 username/password로 인증하지 않고,apiKey 하나로 사용자를 식별하도록 구조를 변경했다.이전 구조에서는 글 작성 시 이런 방식이었다.이 구조에는 여러 문제가 있었다.누군가 다른 사용자의 usern

이번 글은 apiKey 인증으로 전환한 뒤(15강 이후)강의에서 “왜 apiKey가 더 낫다고 말하는지 / 근데 왜 완전 안전한 건 아닌지”를 정리한 내용이다.그리고 17강에서 바로 이어지는 새로운 문제(사용성 문제)까지 같이 정리한다.처음엔 인증이 없어서 사칭(4칭)

18강은 “로그인 기능”을 만들기 전에 회원가입(join) 기능부터 먼저 구현한 파트다.이유는 간단하다. 로그인은 결국 “회원이 이미 존재한다”는 전제가 필요하고, 그 전제를 만들려면 회원가입이 먼저여야 한다.이번 글은 강의 진행 흐름대로✅ 회원가입 테스트 케이스 추가

회원가입 기능을 구현하면서username 중복 체크 로직을 컨트롤러에서 서비스로 이동하는 리팩토링을 진행했다.겉으로 보면 단순한 위치 이동처럼 보이지만,실제로는 에러 처리 품질, 책임 분리, 프론트엔드 협업과 직접적으로 연결되는 중요한 변경이다.그리고 DB에는 이미 다

이번 강의에서는 회원 로그인 기능을 구현했다.이전까지는 회원가입과 API Key 발급 구조를 만들었고,이번 로그인은 단순 인증을 넘어서 API Key를 클라이언트에게 전달하는 역할을 한다.로그인 API 구현로그인 테스트 코드 작성로그인 성공 시 API Key 반환DTO

이번 강의에서는Postman 컬렉션 변수(Collection Variables)를 사용해 apiKey를 관리하는 방법을 배웠다.이제 매 요청마다 apiKey를 직접 입력하지 않고,한 번만 설정해두면 모든 요청에서 자동으로 사용되도록 만든다.지금까지 만든 인증 흐름은 다

이번 강의에서는 Postman의 Script 기능(Post-response) 을 사용해서로그인 성공 시마다 apiKey를 자동으로 컬렉션 변수에 갱신하는 작업을 진행했다.이전 강의까지는 로그인 후 응답으로 받은 apiKey를직접 복사해서 컬렉션 변수에 붙여 넣어야 했던

이번 강의에서는 인증 정보를 URL 파라미터가 아닌 HTTP Header로 옮기는 작업을 진행했다.실무에서 왜 인증 정보를 Header에 담는지, 그리고 스프링에서는 이를 어떻게 받는지까지 정리해보자.이전까지는 글 작성, 댓글 조회 등 API 요청 시 아래처럼 인증 정

이번 강의에서는 Postman에서 Authorization 헤더를 설정하는 올바른 방법을 다뤘다.이전까지는 Headers 탭에서 Authorization 값을 직접 추가했지만,Postman에서는 Authorization 탭을 사용하는 것이 정석적인 방식이다.Header

이번 강의에서는Authorization 헤더가 아예 없는 경우 발생하는 예외를 전역(Global)에서 처리하는 작업을 진행했다.컨트롤러에서 인증 정보를 다음과 같이 받고 있었다.인증 정보는 HTTP 헤더의 Authorization 값@RequestHeader("Auth

이번 강의에서는 Postman의 Authorization(인증 정보) 상속 구조를 정리한다.코드를 수정하는 강의가 아니라, Postman 설정 방식 자체를 이해하는 단계다.Postman의 인증 정보는 상속 구조를 가진다요청(Request)은 폴더(Folder)의 인증

이번 강의에서는 글 수정 API에서도 인증 정보를 전달하고,단순히 “로그인했는지”를 넘어서 해당 글을 수정할 권한이 있는지(인가) 까지 검증하는 로직을 구현했다.사용자가 누구인지 확인하는 과정로그인, API Key 검증 등이 여기에 해당예시아이디 / 비밀번호 확인Aut

이번 강의에서는 글 삭제(DELETE) API에도 인증 정보를 전달하고,삭제 요청자가 해당 글의 작성자인지 권한 체크(인가) 를 추가했다.DELETE /api/v1/posts/{id} 요청에서도 Authorization 헤더(Bearer apiKey) 를 받도록 수정a

이번 강의에서는 댓글 작성 시 로그인한 사용자(인증된 회원)가 자동으로 작성자로 저장되도록 구조를 변경했다.이전까지는 테스트를 위해 임시로 특정 회원(user1)을 작성자로 고정했지만,이제는 Authorization 헤더에 전달된 apiKey를 기준으로 실제 로그인한

이번 30강에서는 댓글 수정/삭제 요청에도 인증 정보(Authorization 헤더)를 전달하도록 맞추고, 그 인증된 사용자가 해당 댓글의 작성자인지(인가, 권한 체크)까지 검증하는 로직을 추가했다.정리하면 흐름은 이거다.인증(Authentication): “너 누구냐

이번 강의에서는 대부분의 컨트롤러에서 반복되던 공통 기능을 모으기 위해Rq라는 클래스를 만들고, 이를 @RequestScope 빈으로 등록했다.핵심은 단 하나다.👉 “요청 하나당 하나의 Rq 객체”를 만들어서현재 요청에 대한 공통 정보(예: 로그인한 사용자)를 관리하

이번 강의에서는 RequestScope 빈의 실제 동작 방식을 다룬다.특히 헷갈리기 쉬운 이 질문에 대한 답이 핵심이다.❓ RequestScope면 접근할 때마다 new 객체가 생성되는 거 아니야?결론부터 말하면 아니다.👉 RequestScope 빈은 요청당 1번만

이번 강의(33강)는 한 줄로 요약하면 이거다.👉 컨트롤러마다 반복되던 “Authorization 헤더 처리 + apiKey로 Member 조회” 로직을 Rq.getActor()로 옮겨서, 컨트롤러를 깔끔하게 만든다.글/댓글 작성·수정·삭제 컨트롤러마다 아래 로직이

이번 강의의 핵심은 아주 단순하다.Rq 클래스는“컨트롤러 수준에서 반복되는 인증/인가 코드를 모아두는 역할”이다.정확한 내부 원리를 처음부터 100% 이해할 필요는 없다.“아, 이거 컨트롤러에서 매번 하던 중복 코드 정리용이구나”이 느낌만 들면 강의 목표는 달성이다.컨

35강을 듣다 보면 이런 생각이 든다. > “Rq는 싱글톤이어도 된다면서?” > “컨트롤러도 하나인데 요청이 동시에 들어오면 섞이는 거 아니야?” > “getActor() 같은 메서드가 여러 번 동시에 실행되면 위험한 거 아냐?” 이 글에서는 이 질문들을 초보자 기

36강에서는 글(Post)과 댓글(PostComment)의 권한 체크 로직을컨트롤러에서 제거하고 엔티티로 이동하는 리팩토링을 진행했다.겉으로 보면 단순히 코드 위치만 바뀐 것 같지만,실제로는 역할 분리 + 객체지향 설계 원칙을 적용한 중요한 변화다.강의에서 먼저 짚고

37강에서는 글 쓰기 요청에 인증 정보가 없을 때서버가 올바르게 401 Unauthorized를 반환하는지 검증하는테스트 케이스를 추가한다.겉으로 보면 단순한 테스트 하나 추가처럼 보이지만,이 강의의 핵심은 “무엇을 꼼꼼하게 테스트해야 하는가”에 있다.이번 커밋에서 변

38강과 39강에서는 새로운 기능을 추가하지 않는다.대신 이미 구현된 인증/인가 로직을 테스트로 단단히 고정한다.두 강의의 성격이 거의 동일하기 때문에,이번 글에서는 38강 + 39강을 한 번에 정리한다.이번 두 강의의 공통 주제는 명확하다.“권한 체크는 반드시 테스트

40강에서는 “내 정보 조회 API” 를 구현한다.지금까지 정리해온 인증 흐름(Rq)을 실제로 활용하는 단계다.핵심은 단순하다.로그인 안 했으면 401,로그인 했으면 내 정보를 내려준다.대부분의 서비스에는 반드시 이런 API가 있다.로그인 상태 확인현재 사용자 정보 조

41강에서는 로그인 시 발급받은 apiKey를 어디에 저장해야 하는지를 다룬다.결론부터 말하면, 브라우저 로컬 스토리지(LocalStorage) 를 사용한다.서버는 모든 요청마다 이렇게 묻는다.“이 요청을 보낸 사람이 누구냐?”그래서 클라이언트는 모든 API 요청마다

42강에서는 XSS(Cross Site Scripting) 공격에 대해 다룬다.이 강의의 핵심은 단순하다.“왜 우리가 아무 생각 없이 화면에 값을 출력하면 위험해질 수 있는가?”XSS (Cross Site Scripting) 는웹 애플리케이션에서 발생하는 대표적인 보안

42강에서 XSS 공격의 개념과 기본 방어를 배웠다면,43강에서는 “그래서 이게 실제로 어떻게 털리는가” 를하나의 현실적인 시나리오로 설명한다.이번 강의의 핵심 메시지는 명확하다.XSS + 로컬 스토리지 = 연쇄적인 계정 탈취 사고현재 서비스의 인증 구조는 다음과 같다

43강에서 우리는 XSS 공격으로 로컬 스토리지에 저장된 apiKey가 탈취되는 시나리오를 봤다.44강에서는 그에 대한 중요한 대안을 다룬다.핵심은 이 문장이다.“쿠키는 fetch 요청 시 자동으로 헤더에 포함된다.”쿠키의 가장 중요한 특징은 이것이다.브라우저가 자동으

44강에서 우리는 쿠키가 fetch 요청 시 자동으로 헤더에 포함된다는 사실을 배웠다.45강에서는 이 동작을 이론이 아니라 실제로 눈으로 확인해본다.이번 강의의 목적은 단순하다.쿠키가 언제 생성되고,어떤 요청에,어떤 방식으로 자동 전송되는지 직접 확인한다이번 테스트는

41강: apiKey를 로컬 스토리지에 저장해 로그인 상태 유지42강: XSS 공격 개념과 프레임워크의 기본 방어43강: XSS로 로컬 스토리지의 apiKey가 탈취되는 실제 시나리오44~45강: 쿠키는 fetch 요청 시 자동으로 전송된다는 점과 쿠키 테스트그리고 여

앞선 강의들에서 우리는 인증 방식의 흐름을 이렇게 정리해왔다.로컬 스토리지 → XSS에 취약쿠키 → 자동 전송 + HttpOnly로 XSS 방어 가능웹 환경에서는 HttpOnly 쿠키가 매우 강력한 선택그런데 여기서 한 가지 중요한 현실적인 문제가 남아 있다.“모든 클

이번 강의에서는 로그인 성공 시 apiKey를 쿠키로 생성하도록 구현한다.핵심 포인트는 다음 한 문장이다.로그인 성공 → 서버가 apiKey를 쿠키(Set-Cookie)로 내려준다이를 통해 브라우저는:apiKey를 자동으로 저장하고이후 요청마다 자동으로 서버에 전송한다

이번 강의에서는 로그인 성공 시 apiKey를 쿠키로 생성하고,보안을 위해 path=/, HttpOnly=true 옵션을 추가하는 과정을 다룬다.또한 테스트 코드와 Postman을 통해쿠키가 실제로 생성되고, 응답에 포함되는지를 검증한다.✔ 로그인 성공 시 apiKey

이번 강의에서는 Spring Boot에서 인증 정보를 Authorization 헤더뿐 아니라 Cookie 헤더에서도 읽어 처리하도록 구현합니다.이로써 웹과 앱 환경을 모두 지원하는 인증 구조가 완성됩니다.환경마다 인증 정보를 전달하는 방식이 다르기 때문입니다.모바일 앱

이번 강의에서는 Rq.getActor() 메서드에 점점 쌓여가던 인증 관련 로직을 정리하고,중복되는 책임을 메서드로 분리하는 리팩토링을 진행했다.핵심은 인증 로직 자체는 유지하면서, 가독성과 안전성을 높이는 것이다.기존 getActor() 메서드는 다음과 같은 문제를

이번 강의에서는 기능 추가나 보안 강화가 아닌,개발 과정에서의 편의성 향상을 위한 개선을 진행했다.핵심은 단 하나다.샘플 회원에 한해서 apiKey를 username과 동일하게 맞춘다.기존 구조에서는회원 생성 시 apiKey가 랜덤 UUID로 생성됨매번 로그인 후 ap

이번 강의에서는 개발 편의성을 위해 사용하던 apiKey = username 설정을 운영 환경(prod)에서는 막는 구조를 만들었다.그리고 이를 위해 Spring Profile(dev / test / prod) 과 AppConfig를 도입했다.이전 단계에서는 개발을 빠