프론트엔드 컨셉 궁금합니다.

jwt는 이미 서버의 암호화 키로 서명이 되어있습니다. 그러니 변조가 불가능하며, payload 데이터의 신뢰성은 충분합니다.

"이렇게 밖에 구성을 못하는 가요?" 라는 질문의 의도를 잘 모르겠습니다.

좀 더 상세히 질문을 주시면, 보다 좋은 답변을 드릴 수 있습니다.

화이팅입니다. :-)

서버에서 jwt token을 만드는 서버의 secret key가 유출되지 않는 한, 본인이 직접 access token을 만드는 것은 기술적으로 불가능합니다. jwt token에는 서명(Signature)의 과정이 들어가기 때문입니다.

말씀하신 대로 프론트엔드 단에서 개발자도구를 통해 UI나 로직을 변경을 하더라도, 변경을 한 그 유저의 프로그램만 일시적으로 변경이 되는 것입니다. 화면 변경은 원천적으로 막을 방법이 없습니다. 막을 필요도 없구요. // 본인의 화면 만 일시적으로 변경하더라도 서버인증을 다른 이로 변경할 수는 없습니다.

Android 앱은 웹에 비해 변경은 어렵지만 프로그램 바이너리를 디컴파일해서 소스코드를 생성해서, 코드 수정은 한 후에 다시 앱을 빌드해서 재포하기도 합니다. 특히 중국에서는 광고를 제거한 게임들이 주로 그렇습니다.

그리고 서버와의 통신을 분석해서, 별도의 클라이언트 프로그램을 만들어서 사용하는 사람도 있습니다. 이걸 리버스 엔지니어링이라고 할 수도 있겠네요. // 이렇게 별도의 클라이언트 프로그램을 만들었다 할지라도, 서버와의 통신에서는 인증을 다른 이로 할 수는 없습니다. 단지 UI만 직접 만든 로직으로 수행될 따름이겠지요.

그러니 클라이언트 단에서 주요 비즈니스 로직을 수행하는 것이 아니라, 서버 단에서 주요 비즈니스 로직을 수행하고 클라이언트 단에서는 UI관련 처리만 하는 것이 나은 접근일 수도 있습니다.

다양하게 고민하고 계시네요. 많이 의심해보시고 고민해보시고 다양한 질문 많이 주세요.

화이팅입니다. :-)

안녕하세요.

본인이 쓴 글일 경우에만 수정/삭제 버튼을 노출하고자 한다면, 각 글마다 작성자 식별자가 필요합니다. 작성자 정보를 매칭하기 위해 JWT 외에 본인의 식별자도 필요할텐데요. 장고 jwt 라이브러리들은 대개 jwt token외에 payload에 user_id를 포함하고 있으니 이를 유저의 식별자로 활용하실 수도 있고, 다른 값이 필요하시다면 payload handler를 커스텀 지정하셔서 payload에 필요한 정보를 더 포함하실 수도 있습니다.

이제 그럼 프론트엔드 측에서 본인 글일 경우에만 수정/삭제 버튼을 노출할 수 있을 것이구요. 서버로 수정/삭제 요청을 보낼 경우에 서버 측에서도 본인 글인지에 대한 체크가 추가로 꼭 필요합니다. 이는 JWT 인증을 거치면 request.user를 통해 현재 요청의 User 인스턴스를 획득할 수 있으니, request.user와 수정/삭제할 리소스 작성자 정보가 비교를 해서 다르다면 요청을 거부토록 작성을 해야겠죠.

프론트엔드 단에서 수정/삭제 버튼을 본인인 경우에만 노출하기에, 백엔드 단에서는 체킹할 필요가 없다고 생각하시는 분들도 계시지만, 절대 그렇게 해서는 안 됩니다. 프론트엔드 단으로부터의 요청은 누구나 변조할 수 있고, 흉내낼 수 있습니다. 서버 단에서는 체킹은 필수입니다.

화이팅입니다. :-)