secretkey의 용도, 토큰의 위,변조 검증, 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를 따로 헤더에 담고 비교하는 게 위변조를 어떻게 알 수 있는지 궁금합니다.

안녕하세요 jwt 토큰 인증 관련 질문드립니다.

1. 강사분이 대답해주신 내용이고 2. 현재 상황은 토큰 검증에 대한 책임을 api gateway가 하고 있으므로 user service에서는 토큰 검증을 하지 않는데요. 만약 필요하다면 api gateway 에서 한 것 처럼 해야겠죠. 3. 토큰 방식을 사용하는 목적이 클라이언트에서 로그인을 관리하는 거니까 클라이언트에서 처리해야 돼요. 클라이언트단에서 로그인 시 어딘가에 토큰을 저장하고 권한이 필요한 요청에는 Authorization 헤더에 해당 토큰을 포함시키는 흐름이죠. 따라서 유저가 로그아웃을 했다면 클라이언트단에서 관리한는 토큰을 지워버리면 로그아웃된다고 생각해요.

패스워드 컬럼을 unique 하게 설정하는 부분에서 질문이 있습니다.

다음 강의를 보니까 답이 나와있었네요 😢 BCryptPasswordEncoder에서 랜덤 Salt를 사용하기 때문에 같은 패스워드일지라도 다른 값으로 암호화된다고 이해했습니다.

JPA Id와 String userId

Unique 한 값이 필요하다면 UserEntity 의 id 값을 사용할 수도 있다고 생각이 드는데요. 이를 ResponseUser 에 사용하여 외부에 노출하면 안 좋은 점이 있나요 ??

필터 질문 드립니다.

해당 강의에서 사용하는 SimpleBeanPropertyFilter는 jackson 라이브러리가 응답을 만드는 과정에서 사용하는 객체로 이름이 필터로 끝나지만 질문자님이 궁금해하시는 필터와는 다른 개념이 아닌가요 ??