# 관련링크 - [재생목록](https://www.youtube.com/playlist?list=PLE0hRBClSk5LQF_Cci7eYRf4Uv2uZZ9Tb) - [몰입코딩 - 스프링부트, 시큐리티 - slog.gg/p/13940](https://slog.gg/p/13940#f) # 1강 - [25 01 07, p 13943, 1강, 프로젝트 생성, GIT PUSH](https://youtu.be/wnOq_qVQgcg) - [GITHUB - 저장소 생성 - https://github.com/new](https://github.com/new) - [GITHUB - 저장소 - https://github.com/jhs512/spring-jwt-2025-01-07](https://github.com/jhs512/spring-jwt-2025-01-07) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/9853fb7) ## 프로젝트 생성 - [스프링 이니셜라이저 - https://start.spring.io/](https://start.spring.io/) - ![img](https://i.postimg.cc/WpsnR3rj/2025-01-07-111231.png) # 2강 - [25 01 07, p 13943, 2강, slog 13940 수업의 26강 소스코드를 복사해서 프로젝트에 적용](https://youtu.be/HGY4IUrJ-Bo) - [몰입코딩 - 스프링부트, REST API 구현 BY TDD - slog.gg/p/13940#26강](https://slog.gg/p/13940#26강) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/0d854b6) # 3강 - [25 01 07, p 13943, 3강, apiKey 방식은 그것이 유효한지 확인하기 위해서는 꼭 1번 이상 DB 조회가 필요하다.](https://youtu.be/l7qG0j2sD90) ## 설명 - apiKey 방식은 그것이 유효한지 확인하기 위해서는 꼭 1번 이상 DB 조회가 필요하다. - 이게 나쁘지는 않지만 더 좋은 방식이 있다. # 4강 - [25 01 07, p 13943, 4강, JWT 방식으로 서명하면 해당 토큰이 유효한지 확인하기 위해서 DB 조회가 필요하지 않다.](https://youtu.be/Pg56qBRImds) ## 설명 - JWT 방식으로 서명하면 해당 토큰이 유효한지 확인하기 위해서 DB 조회가 필요하지 않다. # 5강 - [25 01 07, p 13943, 5강, jjwt 라이브러리 로드, AuthTokenServiceTest 클래스 생성](https://youtu.be/JtlD9T1H3n0) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/73bf00c) # 6강 - [25 01 07, p 13943, 6강, {name="Paul", age=20} 이라는 내용을 기반으로 JWT 생성](https://youtu.be/n0o_qPztqPY) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/1dd2c73) ## JWT 생성에 필요한 것들 - 서명키 (SecretKey) - 서명 알고리즘 (SignatureAlgorithm) - 클레임 (Claims) - 토큰에 담을 데이터 - 예) {name="Paul", age=20} - 만료시간 (Expiration Time) # 7강 - [25 01 07, p 13943, 7강, JWT은 암호화된 결과물이 아니라 단순히 어떠한 내용에 서명이 된 결과물 입니다.](https://youtu.be/Q5cVBfzN9mc) - [JWT 검증 툴 - https://token.dev/](https://token.dev/) ## 설명 - JWT은 암호화된 결과물이 아니라 단순히 어떠한 내용에 서명이 된 결과물 입니다. # 8강 - [25 01 07, p 13943, 8강, 시크릿 키는 추후 어떠한 JWT가 위조되었는지 판별할 때 사용됩니다.](https://youtu.be/cKcov9iLn78) # 9강 - [25 01 07, p 13943, 9강, Ut.json.toString 함수를 이용해서 편하게 JWT 생성](https://youtu.be/ZnyKSzJf6LU) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/c8ba561) # 10강 - [25 01 07, p 13943, 10강, authTokenService.genAccessToken 함수 구현](https://youtu.be/ok9kjdsyLpU) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/f54092f) ## 설명 - 엑세스 토큰은 보통 사용자 인증정보를 담고 있는 토큰을 말한다. - PS. 꼭 JWT 방식의 토큰이 아니어도 엑세스 토큰이라고 부른다. # 11강 - [25 01 07, p 13943, 11강, @Deprecated 어노테이션 이 붙어있는 메서드는 사용하지 않는게 좋다.](https://youtu.be/ci19qICENeA) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/e51c3a8) # 12강 - [25 01 07, p 13943, 12강, JWT 유효성 체크, payload 추출](https://youtu.be/KxHkD-muMvc) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/9d0b68a) # 13강 - [25 01 07, p 13943, 13강, Ut.jwt.isValid(secret, jwtStr) 함수 구현](https://youtu.be/WNdeop6LFU0) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/46889e0) # 14강 - [25 01 07, p 13943, 14강, Map＜String, Object＞를 리턴하는 Ut.jwt.payload(secret, jwtStr) 함수 구현](https://youtu.be/VayFbmamAaA) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/99de6fa) # 15강 - [25 01 07, p 13943, 15강, authTokenService.payload 함수 도입, 함수에서 id를 long 타입으로 형변환](https://youtu.be/14iyjJSpYpo) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/13c286a) # 16강 - [25 01 07, p 13943, 16강, JWT 시크릿키와 엑세스 토큰의 만료기간을 설정파일에서 관리](https://youtu.be/TPV2q6jhNS0) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/efe1885) # 17강 - [25 01 07, p 13943, 17강, 이제 로그인 시 엑세스 토큰을 발급, 기존 apiKey는 삭제하지 않습니다.](https://youtu.be/NYgnX17unok) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/7f7d25f) ## 설명 - 기존 apiKey는 삭제하지 않습니다. - 나중에 apiKey는 리프리시 토큰으로 사용할 것입니다. - 이 내용은 나중에 다룹니다. # 18강 - [25 01 07, p 13943, 18강, AuthTokenService 를 외부에 바로 노출하지 않고 MemberService 의 하위 서비스로서만 사용](https://youtu.be/0UYZxbkjA5k) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/732bde2) ## 설명 - 각 클래스간 결합도는 낮을수록 좋다. - 외부에 바로 노출하지 않고 하위 서비스로서만 사용하면 결합도를 낮출 수 있다. - 나중에 AuthTokenService 의 기능이 많아진다면 해당 클래스를 노출해도 된다. # 19강 - [25 01 07, p 13943, 19강, 이제 apiKey를 통한 인증이 아닌 accessToken을 통한 인증으로 작동](https://youtu.be/Yi4JbDzj3nI) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/677aec1) # 20강 - [25 01 07, p 13943, 20강, 일단 지금부터는 POSTMAN 에서 apiKey가 아닌 accessToken을 Authorization 헤더에 담아야 합니다.](https://youtu.be/PbrykSshBTY) # 21강 - [25 01 07, p 13943, 21강, memberService.getAuthToken 함수는 내부적으로 getAccessToken 함수를 호출](https://youtu.be/n8byv-DWkbY) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/02fbe34) # 22강 - [25 01 07, p 13943, 22강, 여태까지 작업한 내용 정리, apiKey 방식(DB 조회 방식)과 accessToken 방식(JWT 방식) 비교](https://youtu.be/SvzpY92aPlc) ## 🔍 **1. MySQL 쿼리로 인증 (SELECT 쿼리)** ### 쿼리: ```sql SELECT * FROM MEMBER WHERE API_KEY = ?; ``` ### 성능 분석: - **장점**: - 데이터베이스에 저장된 **정확한 최신 데이터**를 사용하여 인증. - **API_KEY가 유효하지 않을 경우** 바로 걸러낼 수 있음. - **단점**: - MySQL 쿼리는 네트워크 지연(Latency)과 I/O가 발생하므로 **데이터베이스 접근 시간이 필요**. - 유니크 인덱스가 걸려 있어도 쿼리 실행 시 **디스크 접근이 필요**하므로 **I/O 오버헤드**가 발생. - **초당 요청이 많을 경우 DB가 병목**이 될 가능성이 있음. ### 예상 쿼리 속도: - **MySQL 유니크 인덱스 쿼리**는 보통 **몇 밀리초(ms)** 내에 응답. - 일반적으로 **3~10ms** 정도 소요. --- ## 🔑 **2. JWT 파싱 방식으로 인증 (시크릿키로 검증)** ### 성능 분석: - **장점**: - **디스크 접근 없이 메모리에서 즉시 처리**하므로 속도가 매우 빠름. - 네트워크 지연 및 데이터베이스 접근이 필요 없음. - **초당 수천 개의 요청을 처리**해도 병목이 발생하지 않음. - **단점**: - JWT는 **토큰 자체에 정보가 포함**되어 있어 **서버에 저장된 최신 데이터와 동기화가 어려움**. - **토큰 탈취** 시 토큰이 만료되기 전까지 보안 이슈 발생 가능. - **리프레시 토큰 관리**가 필요함. ### 예상 처리 속도: - **JWT 파싱**은 **마이크로초(us) 단위**로 처리 가능. - 일반적으로 **0.1~1ms** 이내에 처리됨. --- ## ⚡ **속도 비교** | 인증 방식 | 평균 속도 (ms) | 주요 병목 원인 | |----------------|----------------|-----------------------------| | MySQL 쿼리 | 3~10ms | 네트워크 지연, DB I/O | | JWT 파싱 | 0.1~1ms | CPU 계산 (디지털 서명 검증) | --- ## 🚀 **왜 JWT가 더 빠른가?** 1. **MySQL 쿼리**는 요청마다 **네트워크, 디스크 접근, DB 캐시** 등을 거쳐야 함. 2. 반면, **JWT**는 **서버 메모리에서 즉시 파싱**하고 검증할 수 있으므로 매우 빠름. 3. **MySQL 쿼리**는 초당 수천 개 요청 시 DB 부하가 커질 수 있음. 4. **JWT 파싱**은 서버 CPU에 의존하기 때문에 **병목이 발생할 가능성이 적음**. --- ## 🛠 **성능 최적화를 위한 권장 방법** 1. **짧은 만료 기간을 가진 JWT 토큰을 사용**하여 보안성을 강화. 2. **Redis 같은 캐시 서버**를 사용하여 MySQL 쿼리 빈도를 줄임. 3. **DB 접근이 꼭 필요할 경우** `SELECT *` 대신 **필요한 칼럼만 선택**하여 I/O 비용 절감. --- ## ✅ **결론** - **JWT 파싱 방식**이 훨씬 빠르고, **초당 요청이 많을수록** 차이가 커짐. - 하지만, **보안 및 최신 데이터 동기화**가 중요하다면 DB 쿼리를 병행하거나 캐시 사용을 고려해야 함. # 23강 - [25 01 08, p 13943, 23강, 우리가 토큰에 담은 사용자 id 를 시큐리티 User 객체의 한계 때문에 활용하지 못하고 SELECT로 조회하고 있음](https://youtu.be/rCgQWbTnuKk) # 24강 - [25 01 08, p 13943, 24강, Rq.getActor 함수의 구현을 함수형으로 변형, 함수형이 요새 유행](https://youtu.be/HzPmFbSj-r8) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/5d4a23c) # 25강 - [25 01 08, p 13943, 25강, 시큐리티의 User 객체를 확장해서 id도 담을 수 있도록 함](https://youtu.be/HSFDbinaxvQ) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/5e30be2) # 26강 - [25 01 08, p 13943, 26강, SecurityUser 사용, 내 정보에서는 오류가 발생해서 SELECT 쿼리로 해결](https://youtu.be/snLiFdm-pQk) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/dd380d6) # 27강 - [25 01 08, p 13943, 27강, SecurityUser 사용으로 매번 발생하던 쓸데없는 쿼리가 전부 제거됨](https://youtu.be/yi5t3-35igQ) ## SecurityUser 사용으로 각 요청당 쿼리개수변화 - 회원정보 조회 : 1번 -> 1번 - 글쓰기 : 2번 -> 1번 - 글수정 : 3번 -> 2번 - 글삭제 : 3번 -> 2번 - 내글조회 : 2번 -> 1번 ## Post 클래스의 checkActorCanModify 메서드 - 우리가 야매로 만든 actor 객체로도 권한체크 등이 잘 된다. - 이유는 보통 권한체크할 때 동등성 비교(equals)를 하는데 - BaseEntity 계열의 객체는 동등성 비교시에 오직 id 필드만 비교한다. ```java package com.ll.spring_jwt_2025_01_07.domain.post.post.entity; // 생략 public class Post extends BaseTime { // 생략 public void checkActorCanModify(Member actor) { if (actor == null) throw new ServiceException("401-1", "로그인 후 이용해주세요."); // 아래 코드는 다음과 같다. : if (actor.getId().equals(author.getId())) return; // 이유 1 : BaseEntity 클래스에 @EqualsAndHashCode(onlyExplicitlyIncluded = true) 어노테이션이 있기 때문에 // 이유 2 : BaseEntity 클래스 id 필드에 @EqualsAndHashCode.Include 어노테이션이 있기 때문에 if (actor.equals(author)) return; throw new ServiceException("403-1", "작성자만 글을 수정할 수 있습니다."); } // 생략 } ``` # 28강 - [25 01 08, p 13943, 28강, apiKey 방식과 JWT 방식의 쿼리발생건수 별 비교](https://youtu.be/z4-vOJ99KAA) ## apiKey + User 방식에서의 쿼리발생 건수 - 회원정보 조회 : 2번 - 필터 : 1번 - 컨트롤러 : 1번 - 글쓰기 : 3번 - 필터 : 1번 - 컨트롤러 : 2번 - username을 통해서 id 구하는 쿼리 1번 - 작성자로 저장할 때 authorId가 필요 - 글쓰기 쿼리 1번 - 글수정 : 4번 - 필터 : 1번 - 컨트롤러 : 3번 - findById 로 글 찾기 쿼리 1번 - username을 통해서 id 구하는 쿼리 1번 - 권한체크할 때 글의 주인인지는 id로 비교 - 글수정 쿼리 1번 - 글삭제 : 4번 - 필터 : 1번 - 컨트롤러 : 3번 - findById 로 글 찾기 쿼리 1번 - username을 통해서 id 구하는 쿼리 1번 - 권한체크할 때 글의 주인인지는 id로 비교 - 글삭제 쿼리 1번 - 내글조회(LAZY 로드 제외) : 4번 - 필터 : 1번 - 컨트롤러 : 3번 - username을 통해서 id 구하는 쿼리 1번 - 내글조회할 때 작성자의 username이 아닌 id가 필요 - 내글조회 쿼리 2번 - COUNT 쿼리(경우에 따라서 발생 안할 수 도 있음) - CONTENT 가져오는 쿼리 ## accessToken(JWT) + SecurityUser 방식에서의 쿼리발생 건수 - 회원정보 조회 : 1번 - 컨트롤러 : 1번 - 글쓰기 : 1번 - 컨트롤러 : 1번 - 글쓰기 쿼리 1번 - 글수정 : 2번 - 컨트롤러 : 2번 - findById 로 글 찾기 쿼리 1번 - 글수정 쿼리 1번 - 글삭제 : 2번 - 컨트롤러 : 2번 - findById 로 글 찾기 쿼리 1번 - 글삭제 쿼리 1번 - 내글조회(LAZY 로드 제외) : 2번 - 컨트롤러 : 2번 - 내글조회 쿼리 2번 - COUNT 쿼리(경우에 따라서 발생 안할 수 도 있음) - CONTENT 가져오는 쿼리 ## apiKey + User 방식 vs accessToken(JWT) + SecurityUser 방식 비교 표 | 작업 | apiKey + User 방식 | accessToken(JWT) + SecurityUser 방식 | |------|-------------------|-----------------------------------| | **회원정보 조회** | 2번
- 필터: 1번
- 컨트롤러: 1번 | 1번
- 컨트롤러: 1번 | | **글쓰기** | 3번
- 필터: 1번
- 컨트롤러: 2번
  • username으로 id 조회 1번
  • 글쓰기 쿼리 1번 | 1번
- 컨트롤러: 1번
  • 글쓰기 쿼리 1번 | | **글수정** | 4번
- 필터: 1번
- 컨트롤러: 3번
  • findById로 글 찾기 1번
  • username으로 id 조회 1번
  • 글수정 쿼리 1번 | 2번
- 컨트롤러: 2번
  • findById로 글 찾기 1번
  • 글수정 쿼리 1번 | | **글삭제** | 4번
- 필터: 1번
- 컨트롤러: 3번
  • findById로 글 찾기 1번
  • username으로 id 조회 1번
  • 글삭제 쿼리 1번 | 2번
- 컨트롤러: 2번
  • findById로 글 찾기 1번
  • 글삭제 쿼리 1번 | | **내글조회**
(LAZY 로드 제외) | 4번
- 필터: 1번
- 컨트롤러: 3번
  • username으로 id 조회 1번
  • 내글조회 쿼리 2번
    (COUNT + CONTENT) | 2번
- 컨트롤러: 2번
  • 내글조회 쿼리 2번
    (COUNT + CONTENT) | ## 핵심정리 - JWT 토큰에 id를 포함시킨다. - 사용자 정보가 유효한지 확인하기 위해서 DB 조회를 하지 않고 JWT 파싱을 통해서 확인한다. - Member를 야매로 만든다. - 만약에 Member 객체를 야매로 만들지 않는다면 DB에서 조회해야 한다. - 엔티티의 동등성 비교를 id변수를 기준으로만 계산한다. - SecurityUser를 통해서 Member 객체의 id를 얻을 수 있다. # 29강 - [25 01 08, p 13943, 29강, 글 삭제 테스트에 직접 엑세스 토큰을 추가하는 대신 @WithUserDetails("user1") 로 변경, 하지만 안된다. 안되는데 당연함](https://youtu.be/ik5zgzRydNA) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/52fda9f) # 30강 - [25 01 08, p 13943, 30강, CustomUserDetailsService.loadUserByUsername 메서드가 SecurityUser 객체를 리턴하도록 수정](https://youtu.be/dNP3qJqnvzE) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/e2076c6) # 31강 - [25 01 08, p 13943, 31강, `@WithUserDetails("user1")` 를 달고 있는 글삭제 테스트케이스 작동과정](https://youtu.be/xOP1TFT_90o) ## `@WithUserDetails("user1")` 를 달고 있는 글삭제 테스트케이스 작동과정 1. SecurityContextPersistenceFilter 필터 작동 - customUserDetailsService.loadUserByUsername("user1"); - SELECT * FROM MEMBER WHERE USERNAME = ? - securityUser = SecurityUser(3, "user1"); - SecurityUser 객체 생성 - authentication = Authentication(principal = securityUser); - Authentication 객체 생성(우리가 만든 SecurityUser 객체를 principal 변수에 저장) - SecurityContextHolder.getContext().setAuthentication(authentication); - SecurityContextHolder 객체의 setAuthentication 메서드를 통해서 우리가 만든 Authentication 객체를 Context에 저장 - Context에 저장된 Authentication 객체는 해당 HTTP 요청/응답의 라이프사이클 동안 살아있다. 2. CustomAuthenticationFilter 필터 작동 - 여기에서는 헤더 Authorization 에 토큰이 없기때문에 바로 다음 필터로 넘어간다. 3. UsernamePasswordAuthenticationFilter 필터 작동(X) - 이 필터가 작동하기 전에 만약에 로그인 처리 되었다면 해당 필터는 패스된다. - 현재는 SecurityContextPersistenceFilter 필터에 의해서 이미 로그인처리가 되었기 때문에 패스된다. 4. ApiV1PostController.delete 메서드 작동 - rq.getActor(); - SecurityContextHolder.getContext().getAuthentication().getPrincipal(); - SecurityContext 객체의 getAuthentication 메서드를 통해서 우리가 SecurityContextPersistenceFilter 필터에서 생성하고 저장한 Authentication 객체를 가져온다. - Authentication 객체의 getPrincipal 메서드를 Principal 객체를 가져온다. - 해당 Principal 객체를 SecurityUser 타입으로 형변환 - SecurityUser 객체의 id 필드와 username 필드를 가져온다. - 인증용 야매 Member 객체(actor) 생성 후 반환 - 여기서 야매란 표현을 쓴 이유는 JPA를 통해서 만든게 아니라 우리가 직접 `new Member(id, username);` 과 같은 형식으로 만들었다는 의미 5. 이후 과정 진행 # 32강 - [25 01 08, p 13943, 32강, CustomAuthenticationFilter 가 OncePerRequestFilter 를 상속받은 이유](https://youtu.be/NzLkjD9q7oU) ## 스프링 시큐리티에서 OncePerRequestFilter 를 사용하는 경우 - 하나의 HTTP 요청에 대해서 딱 한번만 실행되어야 하는 필터를 만들 때 사용한다. - 예를들어 JWT 토큰 인증 필터는 한번만 실행되어야 한다. - 만약에 여러번 실행된다면 불필요한 DB 조회가 발생할 수 있다. - 또한 인증이 여러번 시도되면서 예상치 못한 문제가 발생할 수 있다. - 스프링 시큐리티의 필터체인에서 필터가 여러번 실행될 수 있는 상황이 있다. - 예를들어 forward나 include와 같은 요청 디스패처 작업이 발생할 때 - 이런 경우에도 OncePerRequestFilter를 상속받은 필터는 한번만 실행된다. # 33강 - [25 01 08, p 13943, 33강, GET /api/v1/posts/statistic](https://youtu.be/zBcEHmjEGUo) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/00c2041) # 34강 - [25 01 08, p 13943, 34강, GET /api/v1/posts/statistics 로 고침, 관리자만 해당 엔드포인트에 접근가능 하도록](https://youtu.be/oUt_aUBvCK4) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/be9b26d) # 35강 - [25 01 08, p 13943, 35강, 시큐리티 유저객체 생성시 id, username 뿐 아니라 authorities 정보도 추가](https://youtu.be/LM5tPSL73dg) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/7a835aa) # 36강 - [25 01 08, p 13943, 36강, ADMIN_ACTION 권한을 가진 사용자만 통계를 볼 수 있도록 SecurityConfig 세팅](https://youtu.be/Y0f0uOEH-RQ) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/d87f46b) # 37강 - [25 01 08, p 13943, 37강, 시큐리티 관련해서 authenticationEntryPoint 뿐만 아니라 accessDeniedHandler 도 설정해서 401과 403에 대한 처리를 나눠서 진행](https://youtu.be/9tmTWQo0eFA) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/c64ea65) # 38강 - [25 01 08, p 13943, 38강, 관리자만 통계를 볼 수 있다는 것을 체크하는 테스트케이스 2건 작성](https://youtu.be/Zd4nvUHR8ko) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/f009e06) # 39강 - [25 01 08, p 13943, 39강, 시스템이 아직 작기 때문에 회원마다 개별 권한을 부여하는 대신 역할을 부여](https://youtu.be/X_AmaOsmR_s) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/34de95d) ## 설명 - 시스템이 작으면 회원마다 개별 권한을 부여하는 것 보다 - 역할을 부여하는 것이 더 편리하다. - 추후 시스템이 복잡해지고 특정 회원이 특별한 권한을 가지고 있어야 할 때 - 권한을 도입하는 것이 좋다. - `.toString().substring(0, 25)` 라고 햇을 때 가끔 테스트가 실패해서 `.toString().substring(0, 20)`로 변경 # 40강 - [25 01 08, p 13943, 40강, `.hasAuthority("ROLE_ADMIN")` 대신 `.hasRole("ADMIN")` 이렇게 써도 된다.](https://youtu.be/iUft2Ckrli0) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/234927e) ## 설명 - `.hasAuthority("ROLE_ADMIN")` 대신 `.hasRole("ADMIN")` 이렇게 써도 된다. - 다만 역할이름이 `ROLE_` 로 시작하는 경우에만 가능하다. # 41강 - [25 01 08, p 13943, 41강, apiKey 방식 vs accessToken(JWT) 방식 비교](https://youtu.be/WFf-QxPYQ5I) ## 설명 - 흔히 말하는 refreshToken 이 apiKey 토큰과 동일하다.(이 부분은 추후 자세히 알게 됩니다.) - apiKey와 accessToken 방식 둘다 클라이언트에 저장된다. - 클라이언트는 브라우저 일 수도 있고 앱일 수도 있다. - 브라우저는 앱보다 조금 더 보안에 취약하다. - 브라우저에 저장된 인증정보는 해커에게 탈취당하는게 가능하다. ## apiKey 방식의 특징 - DB에 저장 : O - 인증 : DB조회 필요 - 인증속도 : 느림 - 폐기 : 가능(DB에서 변경) - 해킹시 대처 : apiKey 재생성 - 보안성 : 높음 - 해킹을 인지했을 때 대처가 가능하기 때문 ## accessToken(JWT) 방식의 특징 - DB에 저장 : X - 인증 : CPU 연산만으로 처리 - 인증속도 : 빠름 - 폐기 : 불가능 - 해킹시 대처 : 불가능, 유효기간을 30분 이하로 생성 - 보안성 : 낮음 - 해킹을 인지했을 때 대처가 불가능하기 때문 ## apiKey 방식 vs accessToken(JWT) 방식 비교 표 | 구분 | apiKey 방식 | accessToken(JWT) | |---|---|---| | DB에 저장 | O | X | | 인증 | DB조회 필요 | CPU 연산만으로 처리 | | 인증속도 | 느림 | 빠름 | | 폐기 | 가능(DB에서 변경) | 불가능 | | 해킹시 대처 | apiKey 재생성 | 불가능, 유효기간을 30분 이하로 생성 | | 보안성 | 높음 | 낮음 | # 42강 - [25 01 08, p 13943, 42강, accessToken만을 사용하면 로그인 후 일정시간이 지나면 자동으로 로그아웃 된다.](https://youtu.be/ZywsLMDXHwo) ## 설명 - accessToken만을 사용하면 로그인 후 일정시간이 지나면 자동으로 로그아웃 된다. - accessToken의 만료기간이 20분이라면 20분이 지나면 자동으로 로그아웃 된다. - 로그인 시 accessToken과 apiKey를 같이 발급해주고 - 클라이언트에서 accessToken을 사용할 수 있는 동안에는 accessToken을 사용하고 - 그 이후에는 apiKey를 사용하면 로그인이 풀리는 것을 막을 수 있다. - 하지만 더 나은 방법이 있다. - 참고로 apiKey 는 사용빈도가 적을 수 록 좋습니다. # 43강 - [25 01 08, p 13943, 43강, 클라이언트에서 apiKey를 오직 accessToken의 재생성에만 사용하고 그 외에 요청은 accessToken 사용](https://youtu.be/x6--_kfvcr8) ## 설명 - 클라이언트에서 apiKey를 오직 accessToken의 재생성에만 사용하고 그 외에 요청은 accessToken 사용 - 이렇게 하면 로그인 후 일정시간이 지나면 자동으로 로그아웃 되는 것을 막을 수 있다. - 이렇게하면 apiKey의 사용빈도를 획기적으로 줄일 수 있다. # 44강 - [25 01 08, p 13943, 44강, 클라이언트 측에서는 모든 요청을 날린 후 accessToken 만료 예외시 accessToken 재발급/재시도 로직을 구현해야 합니다.](https://youtu.be/yWB8LlZ2Cco) ## 클라이언트 측 코드 예시 ```js try { let response = await fetch("http://localhost:8080/api/v1/posts/1", { headers: { Authorization: `Bearer ${accessToken}` } }); if (response.status === 401) { // accessToken이 만료되었으면 새로운 accessToken을 발급받습니다. const newTokenResponse = await fetch("http://localhost:8080/api/v1/member/newAccessKey", { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } }); const data = await newTokenResponse.json(); // 새로 발급받은 accessToken을 저장 accessToken = data.accessToken; // 원래 요청을 새로운 accessToken으로 재시도 response = await fetch("http://localhost:8080/api/v1/posts/1", { headers: { Authorization: `Bearer ${accessToken}` } }); } const data = await response.json(); console.log(data); } catch (error) { console.error('Error:', error); } ``` # 45강 - [25 01 08, p 13943, 45강, 매 요청마다 accessToken과 apiKey를 함께 보내는 방식, 이제 accessToken 갱신에 대한 책임이 백엔드에 있다.](https://youtu.be/OVNj8SJksO4) ## 설명 - 매 요청마다 accessToken과 apiKey를 함께 보내는 방식은 acccessToken 재발급 로직을 백엔드에 넘길 수 있어서 좋다. - 이제 accessToken 갱신에 대한 책임이 백엔드에 있다. - 이제 클라이언트는 더이상 재시도 로직을 구현할 필요가 없다. - 다만 응답의 헤더에 새로운 accessToken이 있는지 확인해야 한다. - 새로운 accessToken이 있으면 클라이언트는 새로운 accessToken을 저장해야 한다. - 추후 쿠키방식을 통해서 이 코드를 훨씬 더 깔끔하게 줄일 수 있다. ## 클라이언트 측 코드 예시 ```js const response = await fetch("http://localhost:8080/api/v1/posts/1", { headers: { Authorization: `Bearer ${apiKey} ${accessToken}` } }); if (response.headers.has('Authorization')) { const token = response.headers.get('Authorization').substring("Bearer ".length); accessToken = token.split(" ")[1]; } ``` # 46강 - [25 01 08, p 13943, 46강, 매 요청마다 accessToken과 apiKey를 함께 보내는 방식의 단점](https://youtu.be/vUHYN8WVhLc) ## 매 요청마다 accessToken과 apiKey를 함께 보내는 방식의 단점 - 모든 요청의 헤더에 apiKey가 포함되기 때문에 네트워크 전송량이 살짝 늘어난다. - 그 외에 보안적인 면에서는 단점이 없다. - 모든 요청과 응답의 내용은 SSL을 통해서 보호되기 때문 # 47강 - [25 01 08, p 13943, 47강, 각 키별 탈취당했을 때의 대응방안](https://youtu.be/VgzVcpHl62g) ## AccessToken 탈취당했을 때의 대응방안 - 방법이 없음 - 중요한 일을 할 때 2차 인증요구하는 방식을 사용해야 피해를 최소화 할 수 있음 - 해당 토큰의 만료기간까지 해커가 사칭하는 것을 멈출 수 없음 ## apiKey(RefreshToken) 탈취당했을 때의 대응방안 - 사용자가 본인의 계정에 뭔가 이상한 점이 있음을 감지해야 합니다. - 다른 지역에서 로그인되었다는 안내메일로도 알 수 있음 - 이런 기능을 구현하면 보안에 큰 도움이 된다. - 사용자가 본인의 계정에 뭔가 이상한 점이 있음을 감지한다면 `전 기기 로그아웃` 기능을 활용해서 본인의 DB에 있는 apiKey 를 변경해야 합니다. - 이렇게 되면 즉시는 아니더라도 20분안에 해커의 사칭을 막을 수 있습니다. - 엑세스 토큰의 만료기간이 20분이라고 가정 ## accessToken 만료기간과 보안은 서로 반비례 관계 | 만료기간 | 해커의 사칭 가능 시간 | apiKey 재발급 횟수 | |---------|------|-------------------| | 짧음 | 짧음 | 많음 | | 김 | 김 | 적음 | # 48강 - [25 01 08, p 13943, 48강, XSS 공격에 대한 설명](https://youtu.be/HyUn8Lkybck) ## XSS 란 - Cross Site Scripting의 약자 - 웹 애플리케이션에서 일어나는 취약점 - 관리자가 아닌 권한이 없는 사용자가 웹 사이트에 스크립트를 삽입하는 공격기법 - 공격자가 웹 페이지에 악성 스크립트를 삽입하여 다른 사용자의 정보를 탈취하거나 비정상적인 기능을 수행하게 함 ## XSS 공격 예시 - 게시판에 글을 작성할 때 ` ``` # 49강 - [25 01 09, p 13943, 49강, POSTMAN에서 로그인 API 요청 후 엑세스 토큰을 얻고 그것으로 로그인 처리 하는 방법](https://youtu.be/oImZLaLhRG4) # 50강 - [25 01 09, p 13943, 50강, 로그인 상태에서 존재하지 않는 엔드포인트에 접근시 404](https://youtu.be/DpUwASw-8aU) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/a8d291b) # 51강 - [25 01 09, p 13943, 51강, Authorization 헤더에 토큰 2개(형식 : `${apiKey} ${accessToken}`) 를 넣어서 요청하는 방식으로 변경](https://youtu.be/vXCvlhUJEGY) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/6e9a284) # 52강 - [25 01 09, p 13943, 52강, `${apiKey} EMPTY` 와 같은 이상한 엑세스 토큰이 포함된 Authorization 헤더를 사용하는 것은 개발자만 해야한다.](https://youtu.be/gJ8iC9VDMik) # 53강 - [25 01 09, p 13943, 53강, 쿠키는 단순히 헤더이다. 다만 거기에 자동기능이 들어있을 뿐](https://youtu.be/0BXguhIpu4Y) ## 클라이언트 측 코드 예시(우리가 바라는 궁극적인 형태) ```js const response = await fetch("http://localhost:8080/api/v1/posts/1", {credentials: "include"}); // {credentials: "include"} 에 대해서는 나중에 자세히 설명합니다. ``` ## 쿠키란 - 웹 브라우저에 저장되는 작은 데이터 조각 - 서버가 클라이언트에게 보내는 데이터로, 클라이언트는 이를 저장했다가 동일 서버에 재요청시 `자동`으로 전송 - 주요 용도 - 세션 관리 (로그인 상태, 장바구니 등) - 개인화 (사용자 선호도, 테마 등) - 트래킹 (사용자 행동 분석) - 구성요소 - 이름 : 쿠키를 구분하는 키 - 값 : 실제 데이터 - 도메인 : 쿠키가 전송될 서버 도메인 - 경로 : 쿠키가 전송될 서버의 경로 - 만료일 : 쿠키가 언제 삭제될지 - Secure : HTTPS에서만 전송 - HttpOnly : JavaScript에서 접근 불가능 - 참고로 쿠키헤더에는 정보를 여러개 넣을 수 있다. ## 일반 적인 헤더와 쿠키의 다른점 | 구분 | Authorization 헤더 (일반 헤더) | 쿠키 | |------|--------------------------|------| | 처리 방식 | 수동으로 처리해야 함 | 자동으로 처리됨 | | 관리 주체 | 개발자가 직접 헤더에 추가하고 관리해야 함 | 브라우저가 자동으로 관리 | | 요청 포함 | 매 요청마다 수동으로 포함시켜야 함 | 모든 fetch 요청에 자동으로 포함 | | 수정 반영 | - | 서버의 쿠키 수정 요청이 오면 자동으로 반영 | # 54강 - [25 01 09, p 13943, 54강, 서버에서 쿠키를 굽는(만드는) 방법, 응답 헤더에 쿠키를 추가하는 방법](https://youtu.be/Aqn4_Xrafmk) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/19c2f89) ## Rq.setCookie() 메서드 ```java public void setCookie(String name, String value) { ResponseCookie cookie = ResponseCookie.from(name, value) .path("/") .domain("localhost") .sameSite("Strict") .secure(true) .httpOnly(true) .build(); resp.addHeader("Set-Cookie", cookie.toString()); } ``` ## Rq.setCookie() 메서드 옵션 설명 - path="/" : 쿠키가 적용되는 경로를 지정, "/" 는 모든 경로에서 쿠키 사용 가능 - domain="localhost" : 쿠키가 전송될 도메인을 지정 - sameSite="Strict" : CSRF 공격 방지를 위한 설정, 같은 도메인의 요청에서만 쿠키 전송 - secure=true : HTTPS 프로토콜에서만 쿠키 전송 가능 - httpOnly=true : JavaScript에서 쿠키에 접근할 수 없도록 설정, XSS 공격 방지 ## 각 설정의 보안상 의미 - sameSite="Strict" : 교차 사이트 요청 위조(CSRF) 공격 방지 - secure=true : 암호화된 통신에서만 쿠키 전송으로 데이터 탈취 방지 - httpOnly=true : 악성 스크립트의 쿠키 접근 차단으로 XSS 공격 방지 # 55강 - [25 01 09, p 13943, 55강, 쿠키는 브라우저에서만 되고 안드 앱, iOS 앱에서는 기본적으로는 안됩니다. 우리 백엔드는 최대한 다양한 클라이언트에서 로그인 되어야 합니다.](https://youtu.be/rytO6Kuc1sQ) # 56강 - [25 01 09, p 13943, 56강, setCookie 기능을 추후 컨트롤러 뿐 아니라 필터/인터셉터에서도 사용할 수 있기 때문에 Rq에서 구현했습니다.](https://youtu.be/6gB3ngZx-Cg) - [커밋 - Rq.setCookie 제거하고 원시적인 방법으로 회귀(좋지 않음)](https://github.com/jhs512/spring-jwt-2025-01-07/commit/691e999) - [커밋 - BaseController 도입해서 모든 컨트롤러가 공유해야할 만한 기능을 모아둠(더 좋은 방법이 있음)](https://github.com/jhs512/spring-jwt-2025-01-07/commit/06a49b1) - [커밋 - Rq.setCookie 다시 도입](https://github.com/jhs512/spring-jwt-2025-01-07/commit/220c3b0) ## 설명 - Rq 클래스는 컨트롤러 뿐 아니라 필터와 인터셉터에서도 사용될 수 있습니다. - 왜냐하면 Rq가 RequestScope 객체이기 때문입니다. - HttpServletRequest와 HttpServletResponse 객체 관련된 로직이 컨트롤러, 필터, 인터셉터에 존재할 수 있습니다. - Rq를 통해서 해당 중복들을 제거할 수 있습니다. - BaseController 들은 컨트롤러 수준에서의 중복만 제거할 수 있습니다. # 57강 - [25 01 09, p 13943, 57강, CustomAuthenticationFilter 에서 Authorization 헤더에 인증정보가 없다면 쿠키에서도 찾아보도록](https://youtu.be/IhsYYYOel4U) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/e7e56b5) # 58강 - [25 01 09, p 13943, 58강, rq.setHeader 함수 도입](https://youtu.be/ZXueZU_Xeno) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/981be97) # 59강 - [25 01 09, p 13943, 59강, CustomAuthenticationFilter 리팩토링, 1st](https://youtu.be/6si5qOXs8vg) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/6e5ced5) # 60강 - [25 01 09, p 13943, 60강, CustomAuthenticationFilter 리팩토링, 2nd, AuthTokens 레코드 도입](https://youtu.be/DKIh-UUOpoQ) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/60a72a5) # 61강 - [25 01 09, p 13943, 61강, Rq.findByActor 함수 도입, rq.getActor 만으로는 안될 때 사용됨](https://youtu.be/sJ9_UVHLhSo) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/1c76d38) # 62강 - [25 01 09, p 13943, 62강, 로그인 성공시 응답 쿠키에 accessToken 과 apiKey 가 있는지 테스트케이스에서 체크](https://youtu.be/XpqOTtXmSQ0) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/7146d77) # 63강 - [25 01 09, p 13943, 63강, 로그아웃에 대한 테스트케이스 작성, HTTP ONLY 쿠기 설명, 로그아웃을 굳이 서버에서 해야하는 이유](https://youtu.be/mmB39yhruqM) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/deaa11e) ## 일반쿠키와 HTTP ONLY 쿠키 비교 표 | 구분 | 일반 쿠키 | HTTP ONLY 쿠키 | |---|---|---| | JavaScript 접근 | 가능 | 불가능 | | XSS 공격 위험 | 높음 | 없음 | | 주 사용 용도 | 일반적인 데이터 저장 | 보안이 필요한 데이터(세션ID, 토큰 등) | | 설정 방법 | httpOnly=false | httpOnly=true | | 브라우저 지원 | 모든 브라우저 | 대부분의 현대 브라우저 | ## 로그아웃을 굳이 서버에서 해야하는 이유 - 클라이언트에서 쿠키를 삭제하는 것만으로는 HTTP ONLY 쿠키를 삭제할 수 없습니다. - HTTP ONLY 쿠키는 JavaScript로 접근이 불가능하기 때문입니다. - 따라서 서버에서 쿠키의 만료시간을 0으로 설정하여 브라우저가 해당 쿠키를 삭제하도록 해야 합니다. - 이것이 로그아웃을 서버에서 처리해야만 하는 주된 이유입니다. ## 해킹시도코드 예시 - 아래 내용을 XSS 대비가 안되어있는 웹 페이지에서 본문으로 작성했다고 가정 - 아래 글을 보는 모든 사람에게 해당 script 가 실행됨 - 하지만 HTTP ONLY 쿠키는 JavaScript로 접근이 불가능하기 때문에 아래 시도는 실패함 ```html 반가워요!! 잘 부탁드립니다. ^ ^ ``` # 64강 - [25 01 09, p 13943, 64강, 로그아웃 구현, POSTMAN에서 테스트](https://youtu.be/kTOJ6ZN5_nc) - [커밋](https://github.com/jhs512/spring-jwt-2025-01-07/commit/4976c32)

스프링부트, JWT