억세스 토큰을 검증해야 할까요? 정보
억세스 토큰을 검증해야 할까요?
본문
이 내용은 API 개발진들에게는 무관하지만
건설적인 토론(?)은 환영합니다.
문득 궁금해지는게 과연 억세스토큰을 미들웨어를 통해 프론트에서 검증해야 할까?입니다.
1. 짜피 억세스토큰을 쿠키에 담아서 임의 조작하더라도 헤더 정보에 토큰을 담아 보내기 때문에
에러 떨어지므로 상관없다!!(401 에러 반환)
2. 그래도 실시간으로 감지 해서 무언가 액션 (강제 로그아웃 / 리프레시 토큰 사용) 을 하는게 좋다..!
아마도 사이트마다 다소 상이할 것으로 보이지만, 냑 분들의 의견은 어떠신지 궁금합니다.
몇몇 사이트 보니깐 2번 쓰는 곳과 1번 쓰는 곳 다 보이더라구요...
2번의 경우는 쨋든 반복적으로 서버에 요청하므로, 리소스 문제도 무시 못 할 것 같고 ㅠ
참고로 전 2번을 사용하는데 ..굳이 ? 라는 생각이 몇일전부터 들기에
그냥 1번을 사용하면서, 401 에러 떨어지면,
리프레시를 사용해서 재발급 없으면 로그아웃 형태로 가는게 좋지 않을까? 라는 생각이 계속 들더라구요
저걸 확실히 결정을 못하니깐 손을 못대고 있네요 에휴...
좋은 의견 주신 분들께 미리 감사합니다.
1
댓글 12개
전 당연히 2번이라고 생각하고 살아와서 1번은 고려도 안 해 봤다는...
그런데 여러 플랫폼, 그리고 다른 사이트 서비스와의 연동에는 2번이 나은 거 아닐까 하는 생각입니다.
@키스 저도 당연히 2번이라고 생각했는데, 무분별하게 검증 api 를 호출한다는 단점 아닌 단점이 걸려서 작성해봤습니다.
저도 2번이 계속 맞다고는 하지만, 머리가 자꾸 굳이? 라는 생각이 계속 떠나질 않네요
GPT 한테 물어봐도 1번 / 2번 둘다 좋은 방법이나 2번이 그래도 무분별한 호출 어쩌고 하는게 ㅎㅎ
좋은 의견 감사합니다.
저도 똑같은 고민 아닌 고민이 들더라구요.
그래서 결론은
처음 접속 시 user csrf token을 생성해 놓고
모든 폼 전송 또는 다른 요청을 ajax를 통해 요청하고 요청 시에만 header로 보내는 걸로 했습니다만.
로봇이 사람과 동일하게 작동하면 무의미하다. 하지만 없는 것 보다는 좋다. 뭐 이런 정도의 결론으로 합의봤습니다.
@메이드 결국 생각해보면 /me 호출한다고 헤더 정보로 계속 보내니
이것도 난제 아닌 난제네요
캐싱으로 처리를 해야 할지 고민입니다 후....
프론트에서 쿠키에서 엑세스토큰을 들고 늘 서버에 요청하러 들어올텐데, 검증은 서버에서 하는 것 아닐까요? 프론트에서는 그냥 이용만? 만일 프론트에서 검증(키가 유효한지 다른값보다 'credential'을 확인할 수 있는 secure key는 서버만 갖고 있어야...)까지하려면 보안에 뚫릴 수 있는 위험을 늘리는 것은 아닌지...
nextjs가 자꾸만 client->server로 개발방향을 옮기는 것을 보면, 어쩌면 자신들도 클라(프론트)에 너무 공을 들이는 것은 보안적 위협이 높아지기 때문이 아닌가 싶기도합니다.
부족한 지식에 한마디 거듭니다요... 저도 잘 모릅니다. 그냥 공부중...ㅎㅎ;
@xpem 말씀하신데로 저것도 맞지만, 단지 2번을 궁금해 했던거 흔히 하는 표현으로 잠수 했을 때 억세스 혹은 리프레시가 만료 되었을 때
어떠한 액션을 주냐 ? 였는게 문제 였는데
위에 분들이 좋은 의견 주셔서 그리고 xpem 님도 같은 의견이 있어서
그냥 자동 액션 보다는 호출 할 때마다 검증 하는 로직으로 바꿨습니다.
서버에서 검증에서 아이디값을 리턴해 그걸로 데이터 조작 하는 형태로 ..
거기서 실패하면 리프레시 요청 > 거기서 실패 하면 아웃 하는 형태로?
적어 놓고도 헤갈립니다.
@미니님a 리프레시가 만료되었다는 것은 서버에서 알 수 있는 듯하옵니다. secret key로 jwt(액세스토큰)를 풀어서 jwt의 credential 이 valid한가? 만일 틀렸다면 rt를 통해 새로 at를 얻도록 - 심리스(seamless)하게 - 해서 실컷 글쓰고 있다가 submit했는데 글쓰기 안되고 로그인화면으로 가게되는 사용자가 열받게 되는 상황을 없애는 어떤 과정이 필요한 것 같습니다.
@xpem 네 억세스 / 리프레시 둘다 서버에서 확인은 하는데
이제 그게 계속 해서 감시 하느냐?의 고민이였던거죠 뭐
언급하신데로, submit 했는데 글쓰기 안되면 난감하니,
/me 호출 할때 조금 생각해봐야하지 않겠나 ? 라는
next auth(v5)에서는 middleware.ts에서 운용을 돕는 듯하옵니다... orz
그리고 최근 추세는 그냥 페이지 라우팅이 이뤄질 때마다 at를 연장을 시키는 분위기같기도합니다. next auth의 경우 그렇게 하는 듯...
@xpem 훔 이 방법은 생각도 못한 방법이네요
@미니님a blur되었다가 다시 화면이 unblur되면 갱신하기도합니다.
등등 십수가지 경우를 대비하여 next auth 는 세션을 seamless 하게 그걸 구현하는 것 같아요...
