일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- uncheck Exception
- JPA
- 스프링 부트 기능
- Unsatisfied dependency
- spring서버
- json gson 차이
- REST API 규칙
- 복합키
- @IdClass
- Filter
- 스프링 부트 공식 문서
- github
- Q 클래스
- jwt메서드
- 스프링부트오류
- jpa회원가입
- 최종 프로젝트
- Error creating bean with name
- 빈생성안됨
- REST란
- json
- ERD 작성
- git
- jpa에러
- 인텔리제이
- JoinColumn
- 1차캐시
- Spring Spring boot 차이
- queryDSL
- JPA주의사항
- Today
- Total
목록2023/08/25 (2)
Everyday Dev System
서버에서 발급한 Access Token 및 Refresh Token을 어디에 저장해야 할까? 현재 상황 현재 제 프로젝트에서 JWT 토큰을 활용합니다. Access Token이 탈취됐을 때 대비를 위해 Refresh Token 개념을 도입하여, 두 토큰 모두 쿠키에 저장했습니다. 쿠키에 담아 JS 파일에서 토큰 여부를 확인하기 위해 setHttpOnly()를 설정하지 않았습니다. 문제점 클라이언트 측에서 둘다 갖고 있으면 탈취 당할 가능성이 있지 않을까? 고민 먼저, JWT 인증은 서버가 상태를 갖지 않아 클라이언트 측에서 토큰을 저장하고 있어야 합니다. 클라이언트가 사용할 수 있는 저장소는 쿠키, 세션 스토리지, 로컬 스토리지가 있습니다. 이 중 어떤 저장소에 저장할지 선택하기 위해 각 저장소별 차이점..
Access Token과 Refresh Token을 처리할 때 문제점을 발견했습니다. 로직을 요약하면, 클라이언트의 로그인 요청 서버에서 Access Token과 Refresh Token 생성 및 반환 (Refresh Token Redis에 저장) 클라이언트에서 Access Token과 Refresh Token을 쿠키에 저장 (HttpOnly설정) 이와 같습니다. 먼저, Access Token이 만료되기 이전에 요청은 Spring Security Filter Chain을 잘 거쳐 Controller 단에 도달하여 해당 요청(재발급)을 잘 처리합니다. 문제는 만료된 Access Token 으로 요청시 Controller 단에 도달조차 못 한다는 것입니다. 이는 Filter에서 토큰 검증을 거치기 때문에 검..