24b0d121e09c28a8699fe8b115ef046f584e9e9e


주섬주섬 찾아서 나름대로 내린 결론은 이거임.

깊이 있게 이해 하진 못함.. 그냥 이거는 이렇다 수준의 정리임.


참고한 글

https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/


local storage <~ csrf, xss 에 취약함


httponly cookie <~ csrf 에 취약함


same site cookie <~ 프엔, 백엔이 다른 도메인 쓰면 못씀


그래서 보통 session storage에 저장하는 거 같더라고?

문제는 session storage도 xss 공격에는 취약할 수가 있다고하네 ㅇㅇ.

그래서 토큰에 fingerprint를 남기라고 말하는 글을 찾았음.


https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.md#token-sidejacking


글에서 말하는 걸 읽어보면

결국 fingerprint라는게 ...



24b0d121e09c28a8699fe8b115ef046c67f4204b95


1. set-cookie 헤더값에 __Secure-Fgp=<길이 50짜리 랜덤 16진수바이너리> +  SameSite: strict; + Httponly; + Secure; 설정


2. fingerprint를 sha-256으로 해싱해서 jwt의 claim에 추가


언어마다 구현과 세부사항이 다르긴 하겠지만 어느정도 궤는 비슷한가 궁금하다..

백하시는분들 다 이렇게 관리하고 있는 거임..?

진짜 가슴이 웅장해지고 존경스럽네.. 리스펙합니다.


#

그래서 결론은


"클라단에서 할 수 있는 최선은 토큰을 session storage에 보관하는 거고

백에서 fingerprint를 새겨주는 것까지 완료해주면 퍼펙트하다"


이렇게 정리해도 되나.. 궁금함.


---


// 아래는 nextjs 관심없으면 안 읽어도됨


프엔을 nextjs로 구성해서 인증 처리관련해서 찾아보다

생각보다 꽤 까다롭길래 (여러탭 간의 동기화 등)

라이브러리를 찾아봤는데 next auth가 유명한 것 같더라고 ㅇㅇ;


써보니까 개편하긴한데

얘네도 밑단에서는 session에 박아두고 useSession하면서 가져올때

session storage 접근해서 가져오는건가?

과거에 next기반 아닌 cra프로젝트나, 아니면 이렇게 토큰 관련해서 클라단에서 쉽게 처리할 수 있는

라이브러리 없을때 걍 from the scratch로 구현해서 프엔에서 개발했던 거임..?

진짜 이것또한 존경스럽네..