jwt 로그인 구현

[jinmyeongheo]

1. jjwt 라이브러리 적용 : java jwt 라이브러리중 가장 많은 start, 잘 작성된 readME, 풍부한 예시
2. 대칭키 이용한 jwt 암복호화. 동적 키생성
3. 테스트코드 적용 BDDMockito 방식
4. Byte Buddy 에이전트 경고 및 JVM 부트스트랩 클래스 경고 해결
5. intellij gradle 실행 속도 변경 : settings > build, execution, deployment > build tools > gradle 에서 Build and run using , Run tests using 값을 Intellij IDEA로 설정 Gradle(Default) 보다 빠른 속도로 실행가능
6. intellij google format 적용

[heeve1]

Date 클래스를 쓰는게 약간 아쉽군요. 못쓸정도는 아니지만 epochTime이나 java.time 쪽 패키지를 보통 많이들 사용하긴 합니다

[jinmyeongheo]

파라미터로 Date를 받아서 별생각없이 사용했는데 멘토님께서 epochTime이랑 java.time패키지를 말씀해주셔서 한번 찾아 보았습니다.

1. jjwt는 왜 Date 타입을 사용할까?

2017년부터 Date 대신 Instant를 사용하자는 요청이 지속적으로 제기되어 왔습니다.
GitHub 이슈 PR : jwtk/jjwt#884
를 확인해 보니 0.12.x 버전까지는 Date 타입이 유지되었고, 1.0.0 버전부터 Date는 Deprecated되고 Instant 기반으로 변경될 계획이라고 합니다.

pr의 현재 문제 상황
JWT RFC 7519 표준에 따르면 NumericDate는 기본적으로 윤초를 무시한 정수로 표현 하지만 JSON에서는 비정수(소수점)을 허용하여 밀리초까지 표현할 수 있습니다.
따라서, Instant 타입을 사용할 경우 초(epoch seconds)와 밀리초(epoch millis)를 어떻게 구분할지 결정해야 합니다. 이 문제로 인해 현재 코드에는 TODO 주석이 남겨져 있으며 pr이 열려 있는 상태입니다.

todo만 빼면 다 끝난 상황인것 같은데, 그 외에도 jwtParser 문제점 개선과 맞물려 있어서 java8에 대한 지원은 빨리 적용될것 같진 않아 보입니다.

2. EpochTime과 java.time

• epochTime은 UTC 기준으로 경과한 시간을 초나 밀리초로 표현하여 빠른연산이 가능 합니다.
• Date / Calendar 는 아래와 같은 문제가 있었기 때문에 java.time이 등장했고 주요 클래스로는 해당 문제들을 해결할 수 있습니다.

1. Immutable하지 않기 때문에 스레드 세이프하지 않다.
2. 직관적이지 않아 예측하기 힘듬 ex) 내부적으로 UTC를 사용하지만 toString 호출시 시스템 기본 시간대를 반영하여 호출
3. 연산 시 Calendar와 함께 사용

[heeve1]

현재 JwtProvider는 인증토큰을 생성해 내는 비즈니스와 JWT 상세구현이 하나로 작성되어 있습니다. 따라서 createAccessToken 를 어떤 목적으로 테스트해야하느냐를 고민해볼 수 있을 것 같네요.

1. 기술은 모르겠고 여튼 createAccessToken을 만들어내는지 테스트
2. JWT 라이브러리가 정상 동작하는지 테스트

하지만 현재 테스트 코드는 위 둘을 둘다 검증해 복잡해보이는 것 같기도 하네요. (다른 관점에서 테스트의 대상이되는 createAccessToken 메서드가 위 1, 2 의 두가지 일을 하게됨에 따라 테스트가 복잡해졌나? 라고 생각해볼만한 지점이기도 합니다)

[jinmyeongheo]

테스트의 목적이 모호할 수 있으니 생성과 동작 검증에 대해 분리하여 처리하도록 하겠습니다.

[heeve1]

패키지 구조 등은 보다 복잡한 도메인을 개발하며 논의해보는게 좋을 것 같아 우선 로그인 개발할때는 크게 신경쓰지 않으셔도 될 것 같습니다!

인가 정책이나 인증쪽 보강도 추후 챙겨서 진행해보시면 좋을 것 같구요~