JWT, OAuth 필기

https://velog.io/@badahertz52/%ED%94%84%EB%A1%A0%ED%8A%B8-%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-JWT-AccessToken-RefreshToken-%EB%8B%A4%EB%A3%A8%EA%B8%B0

https://inpa.tistory.com/559#jwt_json_web_token_%EC%9D%B4%EB%9E%80

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT

https://velog.io/@yaaloo/Security-JWT-%EB%A1%9C%EC%BB%AC-%EC%86%8C%EC%85%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%ED%8A%9C%ED%86%A0%EB%A6%AC%EC%96%BC

OAuth

access token, refresh token을 어디에 저장할까

JWT 토큰 중 access token은 유출을 막는게 좋으니 코드 내 변수로 저장하고(JS private 변수에 저장하면 JS 런타임에서만 접근가능하여 브라우저에서 접근 못하므로 XSS에 대응가능하고, 쿠키에 담는 방식이 아니기 때문에 CSRF도 대응 가능), refresh token은 httpOnly 쿠키로 받아서 저장하는 걸 대체로 추천한다고 함.

로컬 스토리지나 쿠키나 장단점이 서로 있지만, 쿠키를 추천하는 이유는, 로컬 스토리지는 XSS에 취약한데, 이 경우 토큰 값 자체를 탈취당한다. (쿠키는 CSRF에 취약하다)

refresh token은 단순히 access token 발급 용도 토큰이기 때문에 사용자의 민감한 정보가 담기지 않을 뿐더러, httpOnly 쿠키 방식을 통해 JS로 토큰을 탈취하는 XSS를 방지하고, 탈취 당하더라도 refresh token rotation(RTR)을 통해 탈취된 refresh token의 사용을 막을 수 있기 때문이라고 한다.