[TodayKeywords] 오늘 공부한 키워드
AOP(Aspect Oriented Programming): 공통관심사를 주로 처리한다. aop의 공통 관심사는, 로직내에서 반복되는 로직이라기 보단, 로깅과 같이 메소드의 흐름을 전체적으로 봐야하는 로직을 의미하는 것 같다. 비즈니스에서 핵심로직은 공통관심사가 아닌, 해당 로직에서의 주요관심사이기에, 분리 될 수 없다.IllegalArgumentException: 메소드가 적합하지않은 인자를 넘겨받았을 때 발생시키는 오류이다.Claim 기반토큰: 사용자 데이터를 가지고 있는 토큰Spring controller return 타입:@ResponseBody의 형태에 따라, 자동으로 response header 의 contents-type이 셋팅된다.Access Token: 로그인 이후, 해당 유저를 인증하기 위한 토큰이다. 해당 토큰을 헤더에 넣어보내면 재인증할 필요없이 정보를 이용하거나 생성할 수 있게한다. 다만, 도난 시에 다른 상대도 로그인 된 것처럼 사용할 수 있기에, 보안에 대한 이슈가 있다. 따라서, 이 토큰의 만료시간은 보통 1시간에서 2시간으로 짧게 둔다.Refresh Token: Access Token 이 만료되거나, 도난되었을 때 새로운 Access Token을 발급받기 위한 토큰이다. 즉, 토큰을 위한 토큰이다. 해당 토큰의 만료기간은 1~2개월 정도 가지며, 서버에 저장하고 이용하는 방식과, 클라이언트에 저장하고 이용하는 방식 2가지로 설계가 가능하다.@Builder: 해당 어노테이션을 사용하면 모든 세터가 생기고, 그걸 빌더라는 메소드를 통해 한번에 가져오는게 가능한, 빌더패턴이 생성된다.
[NextKeyworks] Study Queue
- HTTPS
- SOLID
- loop label
- CSV
- 파일입출력
- UML
- UTC
- epoch time / Instant time
- MVC
- URL ClassLoader
- Secure ClassLoader
- JNI
- GC
- HOF
- 자바 해시코드(hashCode)
- OSI 7 계층
- PCB
- 스프링 설계철학
- RESTful
- 준 영속성
- 지연로딩
- 프록시객체
- jpa - mybatis 의 차이
- orm - mapper 의 차이
- 쿠키/세션/로컬 스토리지
- HttpMessageConverter
[회고] 221215 : 인증과 인가
오늘은 2차과제를 마무리하고, 추가 구현사항인 Refresh Token과 Access Token을 구현하는데 집중했다. JWT라는 것이 많은 정보를 집약해서 만드는 것이기 때문에 사용이 번거로워 계속 피해다녔는데, 이번에 프로젝트 속도를 낼 수 있게 되면서 직접 구현부터 시작해서 JWT를 이용하여 Refresh Token과 Access Token 까지 건들여보았다. 처음엔 개념이 잘 와닿지 않았지만, JWT라는게 내 정보를 들고다니는 것인데, 그걸을 남한테 강탈당할 경우를 생각을 못했다. 따라서, access token의 만료시간을 1시간에서 2시간정도로 짧게 설정해주고, Refresh Token이라는 것을 두어 이것이 있다면, 지속적으로 로그인을 유지하는 것이 가능하도록 설계한 것이다. 처음엔, 이 모든 토큰을 클라이언트에 저장하여 검증하려고 했는데, 로컬/세션스토리지는 까볼 수 있기 때문에, 강탈의 위험이 있다고 판단했다. 따라서, 거의 세션-쿠키방식으로 DB를 하나 더 생성하여, Refresh Token만 DB를 통해 검증하도록 로직을 만들었다. 우아한 형제들에서 작성한 테코블이라는 블로그에도 비슷한 고민을 한 흔적이 있었고, 그것을 참고했을 때 DB에 저장하는 것이 안정적이라는 판단이 들어 RefreshToken을 저장하는 테이블을 만들고, 이곳에서 검증하도록 했다.
다만, 토큰의 검증을 위해서 어떤 로직이 실행될 때마다, RefreshToken을 저장하는 테이블을 읽는 것이 문제가 될 여지가 있다.. 그렇다면, 어떻게 오버헤드를 줄일 수 있을까? 로직의 분리 혹은 검증을 단순화하는 방안을 고민해보아야겠다.