해결된 질문
작성
·
498
·
수정됨
1
안녕하세요 선생님 질문이 있습니다.
TokenBasedRememberService#processAutoLoginCookie 과정에서
String expectedTokenSignature = makeTokenSignature(tokenExpiryTime, userDetails.getUsername(),
userDetails.getPassword());
if (!equals(expectedTokenSignature, cookieTokens[2])) {
throw new InvalidCookieException("Cookie token[2] contained signature '" + cookieTokens[2]
+ "' but expected '" + expectedTokenSignature + "'");
위와 같이 해당 RemeberService가 생성되었을시 주입받은 key를 가지고 md5 방식으로 tokenSignature를 만드는것을 확인하였습니다.
이것을 받아온 rembemer me token하고 비교하는 것을 확인하였습니다.
질문이 2개입니다.
1) 이 과정을 거쳐서 만든 RememberMeAuthenticationToken 은
왜 아직 ProviderManager.authenticate를 거치지도 않았는데 authenticated=true인것 인가요?
2) 위의 인증객체(RememberMeAuthenticationToken )를 인증할때 RememberMeAuthenticationProvider#authenticate에서 key값을 추가적으로 비교하는 이유가 다른 질문을 찾아보니
"그리고 RememberMeServices 인터페이스를 커스텀하게 자체 기능을 구현할 수 있기 때문에 이 때에도 위와 같은 인증단계의 규칙을 거치게 함으로서 상호간 key 가 일치하지는 여부를 체크하기 위함이기도 합니다."
하셨는데 key가 달라도 MD5digest해서 나온 값이 같을 수도 있어서 추가적으로 검증한다고 이해하면 되나요?
답변 1
1
1번 질문
해당 시점에서의 RememberMeAuthenticationToken 은 최종적으로 인증을 받았다라는 의미보다는 Remember-me 토큰의 유효성이 통과되었다라는 의미가 맞습니다. 굳이 표현하자면 1차 인증 성공이라 할 수 있고 이후 해시된 key 값을 검증하는 최종 인증을 위한 처리가 이루어지게 된다고 보시면 됩니다. 여담이지만 스프링 시큐리티에서 인증을 검증하고 성공시키는 처리는 무슨 특별한 룰이 있다기 보다는 보안적으로 더 잘 설계된 구조안에서 처리하기 위한 단계를 거친다고 보면 될 것 같습니다.
2번 질문
일반적으로 인증 시 key 를 통해 암복호화 하거나 검증하는 방식은 private 한 키값을 통해 생성된 해시값은 인증을 시도하는 사용자가 동일한 키가 아니면 똑같은 해시 값을 만들어 낼 수 없다는 것을 증명하는 과정이라 볼 수 있습니다. 그런 관점에서 시큐리티 초기화 때 키값을 통해 만들어진 Remeber-me 쿠기값을 사용해 인증을 받기 위해서는 인증 시도자가 똑 같은 키를 가지고 있어야만 인증이 성공한다라는 개념이라 볼 수 있습니다.
그리고 MD5digest 는 해시값을 만들어 내는데 키가 다르면 똑같은 결과가 나올 수 없습니다.
요약하자면 토큰이든 쿠키든 대칭 혹은 비대칭키로 만들어진 해시 암호문은 동일한 키 혹은 검증할 수 있는 공개키에 의해 증명할 수 있다는 개념으로 이해하시면 됩니다.