자주 쓰는 라이브러리 두 개가 있습니다.
저번 글에 있었던 구조 사진의 사이트는 oauth0 측에서 구현한 라이브러리이며
Okta또한 동시에 다루도록 하겠습니다.
Builder 패턴으로 클레임 추가가 가능한 것처럼 보입니다.
암호화 알고리즘 또한 선택 가능하고 인코더 비밀번호 키도 설정 가능합니다.
마지막 compact 메소드는 base64로 인코딩 해주는 메소드 같습니다.
여기서 재밌었던 점은 비밀번호 길이가 짧을 때
이런 에러를 발생시킨다는 점 입니다.
그럼 비밀번호 길이를 늘리면
이렇게 base64 형식으로 올바르게 값이 나오는 것을 확인 할 수 있었습니다.
.을 기준으로 스플릿 후에 배열로 잘라내어 저장해서 각각 디코딩 하는 코드입니다!
이 형식을 다시 base64 Decode 해본다면
제가 설정했던 그대로 알고리즘, name, price가 출력됨을 알 수 있습니다.
전 테스트랑 다른 라이브러리를 통해서 똑같이 출력했을 때
크게 다른 점은 없지만 타입이 들어가 있는 것을 알 수 있습니다.
중요한 점은
두 가지 다른 라이브러리로 만든 토큰이 있었을 때
일단 코드상의 각각 검증과정입니다.
다른 라이브러리답게 방법이 다릅니다.
[결과]
그렇다면 본론으로 돌아가서
JWT 로 만든 oauth0_token 을 Jwts로 parser 즉 디코더가 가능한지 알아보겠습니다.
디코더가 가능하지만 일단 위의 코드는 에러가 발생합니다 왜냐면
JWT는 키를 해싱 하지 않고 들어가는 반면
JWTS는 비밀번호 키를 알아서 해싱 해주고 들어가기 때문입니다.
해결방법은 처음부터 키값을 base64 형식으로 변환해서 공통적으로 넣어주는 방법입니다.
이렇게 진행하면 테스트는 문제없이 진행되고 다른 라이브러리여도 디코더, 검증이 가능하다는 것을
알 수 있습니다.
만료시간 테스트도 해보겠습니다.
다음과 같이 만료시간을 두고 스레드 슬립을 통해 7초 후 토큰 디코더를 요청했을때는
Expired 에러가 발생합니다.
아니면 notbefor 클레임을 추가해 2초뒤에 유효함을 설정할 수 있습니다.
아래처럼 유효하진 않아도 직접 확인은 해볼 수 있습니다.
참고 :
스프링부트 Java/Spring 웹 개발 마스터 초격차 패키지 ,
