Spring 심화 주차5일차
1. 오늘 배운 사항
1) n to n 어노테이션에서 옵션
//사용 예시
@Entity
public clase Parent{
...
@OneToMany(mappedBy = "parent", cascade = CascadeType.REMOVE)
private Name name;
...
}
- Mappedby : n to n 관계에서 해당 필드의 소유자가 누구인지 알려 주는 것이다.
- Portfolio 엔티티에서 포트폴리오의 작성자인 User user에 대해서 @OneToOne(mappedby = "portfolo") 어노테이션을 적용했다고 가정 했을 때 portfolio만 정보를 조회해도 user의 이름, 나이 등 신상정보가 같이 조회 된다.
- cascade : 영속성 전이의 특징을 선택할 수 있다. 부모 엔티티에서 자식인 변수에 옵션을 건다.
- ALL : 상위 엔티티에서 하위 엔티티로 모든 작업 전파
- PERSIST : 하위 엔티티까지 영속성 전달
- MERGE : 하위 엔티티까지 병합 작업을 지속
- REMOVE : 하위 엔티티까지 제거 작업을 지속
- REFRESH : 데이터베이스로 부터 인스턴스 값을 다시 읽어오기, 하위 엔티티까지 값을 새로 고침
- DETACH : 연결된 하위 엔티티까지 영속성 제거
2)AccessToken, RefreshToken
- AccessToKen : 접근 관여 토큰 으로, 발급이후 서버에 저장이 안되고 토큰 자체로만 검증하여 인증한다.
- 토큰이 탈취되면 만료 전까지 접근 보안성이 매우 떨어진다.
- 만료 기간을 짧게 함으로써 최소화 할 수 있지만 한계가 명확하고, 자주 로그인 해주고 발급받아야 하는 단점 발생
- RefreshToken : 재발급에 관여하는 토큰
- 처음 로그인시 클라이언트에게 Access와 Refresh를 동시 발급 하고
- 서버는 DB에 Refresh를 저장, 클라이언트는 Access와 Refresh를 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을 때 마다 이둘을 헤더에 담아서 보낸다.
- RefreshToken은 긴 유효기간을 지니면서, AccessToken이 만료됐을 때 새로 재발급 해주는 열쇠가 된다.
- 즉, 만료된 Accesstoken을 보내면 RefreshToken을 DB에 있는 것과 비교하여 AccessToken을 재발급해주는 원리
- 사용자가 로그아웃을 하면 저장소에서 RefreshToken을 삭제하여 사용이 불가능하도록 하고 로그인 시 다시 재발급하여 DB에 저장한다.
- Access/RefreshToken 재발급 원리
- 로그인 시 Access와 Refresh 모두 발급, 이때 Refresh만 서버측에 저장, 클라이언트는 둘 다 저장
- 사용자가 인증이 필요한 API에 접근하면 가장 먼저 토큰 검사
- Access와 Refresh 모두 만료 > 에러 발생 (재로그인 필요)
- Access만 만료 > Refresh 검증하여 access 재발급
- Refresh만 만료 > access 검증하여 Refresh재발급
- Access와 Refresh 모두 유효 > 정상 처리
- RefreshToken 인증 과정
3)Swagger
- 애플리케이션의 RESTful API 문서를 자동으로 구성하고 UI에서 직접 API로 테스트 할 수 있게 해준다.
- 적용 방법 : https://milenote.tistory.com/67
2. 참고자료
1) Cascade 옵션 : https://data-make.tistory.com/668
2) RefreshToken과 AccessToken : https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT