[authentication] 토큰 인증 및 쿠키

Http는 stateless입니다. 귀하에게 권한을 부여하려면 서버로 보내는 모든 단일 요청에 “서명”해야합니다.

토큰 인증

• 서버에 대한 요청은 “토큰”으로 서명됩니다. 일반적으로 특정 http 헤더를 설정하는 것을 의미하지만 http 요청 (POST 본문 등)의 어느 부분으로나 보낼 수 있습니다.

• 장점 :

  • 승인하려는 요청 만 승인 할 수 있습니다. (쿠키-인증 쿠키조차도 매 요청마다 전송됩니다.)
  • XSRF에 대한 면역 (XSRF의 간단한 예-이메일로 링크를 보내드립니다. <img src="http://bank.com?withdraw=1000&to=myself" />쿠키 인증을 통해 bank.com에 로그인 한 경우 bank.com에 XSRF의 수단이 없습니다. 브라우저에서 해당 URL에 대한 승인 된 GET 요청을 트리거한다는 사실만으로 계정에서 돈을 인출 할 수 있습니다.) 쿠키 기반 인증으로 수행 할 수있는 위조 방지 조치가 있지만이를 구현해야합니다.
  • 쿠키는 단일 도메인에 바인딩됩니다. 도메인 foo.com에서 생성 된 쿠키는 도메인 bar.com에서 읽을 수 없지만 원하는 도메인으로 토큰을 보낼 수 있습니다. 이 기능은 인증이 필요한 여러 서비스를 사용하는 단일 페이지 응용 프로그램에 특히 유용합니다. 따라서 myapp.com 도메인에 myservice1.com 및 myservice2.com에 대한 승인 된 클라이언트 측 요청을 수행 할 수있는 웹앱을 가질 수 있습니다.
• 단점 :
  • 어딘가에 토큰을 저장해야합니다. 쿠키는 “즉시”저장됩니다. 기억해야 할 위치는 localStorage (con : 브라우저 창을 닫은 후에도 토큰이 유지됨), sessionStorage (pro : 브라우저 창을 닫은 후에는 토큰이 삭제됨, con : 새 탭에서 링크를 열면 해당 탭이 렌더링 됨) 익명) 및 쿠키 (Pro : 브라우저 창을 닫으면 토큰이 삭제됩니다. 세션 쿠키를 사용하는 경우 새 탭에서 링크를 열 때 인증되며 인증을 무시하므로 XSRF에 영향을받지 않습니다. 인증 쿠키, 당신은 단지 토큰 저장소로 사용하고 있습니다. 장소 : 쿠키는 모든 단일 요청에 대해 전송됩니다.이 쿠키가 https로 표시되지 않은 경우 중간 공격에 노출 될 수 있습니다.)
  • 토큰 기반 인증에 대해 XSS 공격을 수행하는 것이 약간 더 쉽습니다 (예 : 사이트에서 삽입 된 스크립트를 실행할 수있는 경우 토큰을 도용 할 수 있지만 쿠키 기반 인증은 은색 총알이 아닙니다. http-only는 클라이언트가 읽을 수 없으며 클라이언트는 여전히 권한 쿠키를 자동으로 포함하도록 귀하를 대신하여 요청할 수 있습니다.)
  • 인증 된 사용자에게만 적합한 파일 다운로드 요청에는 File API를 사용해야합니다. 쿠키 기반 인증을 위해 동일한 요청이 즉시 수행됩니다.

쿠키 인증

• 서버에 대한 요청은 항상 권한 부여 쿠키로 로그인됩니다.
• 장점 :
  • 쿠키는 “http-only”로 표시되어 클라이언트 측에서 읽을 수 없게합니다. 이것은 XSS 공격 보호에 더 좋습니다.
  • 기본 제공-클라이언트 측에서 코드를 구현할 필요가 없습니다.
• 단점 :
  • 단일 도메인에 바인딩됩니다. (따라서 여러 서비스를 요청하는 단일 페이지 응용 프로그램이 있으면 리버스 프록시와 같은 미친 일을 끝낼 수 있습니다.)
  • XSRF에 취약합니다. 사이트 간 요청 위조로부터 사이트를 보호하려면 추가 조치를 구현해야합니다.
  • 모든 단일 요청에 대해 전송됩니다 (인증이 필요없는 요청에 대해서도).

전반적으로 토큰이 더 나은 유연성을 제공한다고 말하고 싶습니다 (단일 도메인에 바인딩되어 있지 않기 때문에). 단점은 스스로 코딩을해야한다는 것입니다.

답변