secretkey의 용도, 토큰의 위,변조 검증, userId검증로직 질문드립니다.

안녕하세요, 이도원입니다. 

secret key는 토큰을 생성하기 위한 키워드로 사용되고 있고, 간단하게나 복잡하게 작성할수 있습니다. 따라서 얼마든지 유추해 낼수 있습니다. 실제로 (나쁜의미에서의 )해킹을 시도하는 사람들은 정말 단순한 방법을 통해 ㅋ키나 암호를 유추해 내는 과정부터 시작합니다. 따라서 얼마든지 노출될 위험은 있습니다. 말씀하신 것처럼 노출되지 않았다면 문제될 일은 없겠지요. 추가로 header에 userId를 저장한 이유는 토큰에 저장된 userId와 비교하는 용도라고 보시면 될 것 같습니다. 웹 사이트에서 어떤 파일을 다운로드 받을 때 해당 파일에 대한 checksum을 제공하는 이유가 원래 파일의 사이즈와 다운받은 파일의 사이즈 등을 비교해서 문제가 있는 파일인지의 여부를 1차적으로 확인할 수 있는 것처럼, 사용자에게 전달된 토큰과 userId를 비교함으로써, userId가 안전하는 것을 확인해 볼 수도 있을 겁니다. 불필요한 작업이라 판단되시면 삭제해도 무방합니다. 

감사합니다. 

저도 강의를 보면서 이 부분이 이해가 안가서 댓글 남깁니다.

반복적으로 들어오는 질문인 것 같은데.

다른 질문들의 답변을 읽어도 와닿지가 않네요.

강사님이 아니더라도 이해하신분은 답글 남겨주세요 🙏

애초에 secret key 가 노출되지 않았으면 토큰을 위조(토큰을 새로 만듬) 하거나 변조(토큰을 수정) 할 수 있나요?

secret 값을 모르는 상황에서 토큰을 위변조해봤자. 서버에서 토큰을 parse 과정에서 에러가 발생하겠죠.

만약 secret key가 노출되어서 위변조 할 수 있다고 가정하면. 위변조 하는 사람이 토큰을 만들 때 사용한 userId 를 userId header에 담아주면 userId를 비교하는 로직은 의미가 없는 게 아닌가요?

강사님의 위의 답변 중 일부 내용입니다. 

apigateway-service의 header 값에 token과 userId를 직접 전달하고, 복호화 된 token의 정보(userId를 저장하였습니다)와 userId를 비교하여 token의 위변조가 없었는지 확인할 수도 있고

token의 userId는 payload 부분에 들어있고 payload는 암호화가 아닌 base64로 인코딩 되어있기 때문에 secret key 가 없어도 누구나 decode 할 수 있죠. 누구나 얻어낼 수 있는 userId를 따로 헤더에 담고 비교하는 게 위변조를 어떻게 알 수 있는지 궁금합니다.

안녕하세요, 이도원입니다. 

token에 userId를 저장하였기 때문에, 해당 토큰이 정상적으로 복호화 되었다면, 취득하게 되는 userId의 정상유무 및 권한유무 등을 확인해 보실 수 있습니다. 말씀하신 내용에서 secret key 값이 없이 token을 복호화 할 수 있다는 것은 어떤 의미인지 알려주실 수 있을까요? apigateway-service에 있는 AuthorizationHeaderFilter.java의 isJwtValid메소드에서 다음과 같이 signing key를 이용하여 복호화를 하고 있으며, 

try {
    subject = Jwts
            .parser()
            .setSigningKey(env.getProperty("token.secret"))
            .parseClaimsJws(jwt).getBody()
            .getSubject();
} catch (Exception ex) {
    returnValue = false;
}

해당 키가 틀릴 경우에는 다음과 같이 오류가 발생하고 있습니다. 

"JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted."

apigateway-service에서 1차적으로 token의 유무 및 사용가능 여부를 확인 후에 user-service로 요청을 넘기고 있어서, 특정 API의 접근을 제어하고 있습니다. 물론 user-service에서도 인증에 관련된 부분이 추가되면 더 안전할 것입니다. apigateway-service의 header 값에 token과 userId를 직접 전달하고, 복호화 된 token의 정보(userId를 저장하였습니다)와 userId를 비교하여 token의 위변조가 없었는지 확인할 수도 있고, DB에서 확인하거나, 별도위 인증 서비스를 추가하여 해당 token이 정상인지 확인하도록 할수도 있습니다. 

추가 질문사항 있으시면 글 남겨주세요.

감사합니다.