토큰 인증 및 쿠키

토큰 인증 및 쿠키

---

쿠키를 사용한 토큰 인증과 인증의 차이점은 무엇입니까?

Ember Auth Rails 데모 를 구현하려고 하는데, "왜 토큰 인증?"질문 에 대한 Ember Auth FAQ 에 설명 된대로 토큰 인증을 사용해야 하는 이유를 이해하지 못합니다.

---

일반적인 웹 앱은 요청 / 응답 특성으로 인해 대부분 상태 비 저장 입니다. HTTP 프로토콜은 상태 비 저장 프로토콜 의 가장 좋은 예입니다 . 그러나 대부분의 웹앱은 상태 를 유지하기 위해 서버와 클라이언트 사이 의 상태 를 유지하기 위해 서버가 모든 응답을 클라이언트로 다시 보낼 수 있도록 쿠키가 사용됩니다. 이는 클라이언트로부터의 다음 요청에이 쿠키가 포함되어 서버에서 인식됨을 의미합니다. 이런 식으로 서버는 상태 비 저장 클라이언트 와의 세션 을 유지하면서 대부분 앱 상태 에 대한 모든 것을 알고 있지만 서버에 저장됩니다. 이 시나리오에서 클라이언트는 즉시 보유하지 않습니다state . 이것은 Ember.js의 작동 방식이 아닙니다 .

Ember.js에서는 상황이 다릅니다. Ember.js는 서버에서 상태 데이터를 요구할 필요없이 모든 순간에 해당 상태 에 대해 알기 때문에 클라이언트에서 실제로 상태 를 유지하므로 프로그래머의 작업이 쉬워집니다 .

그러나 클라이언트에서 상태 를 유지하면 상태 비 저장 상황 에서는 표시되지 않는 동시성 문제가 발생할 수도 있습니다. 그러나 Ember.js는이 문제를 처리하며 특히 ember-data는이를 염두에두고 작성됩니다. 결론적으로 Ember.js는 상태 저장 클라이언트를 위해 설계된 프레임 워크입니다 .

Ember.js는 세션 , 상태 및 해당 쿠키가 서버에서 거의 완전히 처리 되는 일반적인 상태 비 저장 웹 앱 처럼 작동하지 않습니다 . Ember.js는 자바 스크립트 (클라이언트의 메모리에서, 다른 프레임 워크와 같은 DOM에서는 아님) 에서 상태를 완전히 유지 하며 세션을 관리하기 위해 서버가 필요하지 않습니다. 이로 인해 Ember.js는 앱이 오프라인 모드에있는 경우와 같이 여러 상황에서 더욱 다양합니다.

보안상의 이유로 인증 을 받기 위해 요청을 할 때마다 서버에 어떤 종류의 토큰 이나 고유 키 를 보내야 합니다 . 이렇게하면 서버가 송신 토큰 (서버에서 처음 발행 한)을 조회 할 수 있습니다. 클라이언트에게 응답을 다시 보내기 전에 유효한지 확인하십시오.

필자의 의견으로는 Ember Auth FAQ에 명시된 쿠키 대신 인증 토큰을 사용하는 주된 이유 는 주로 Ember.js 프레임 워크의 특성과 스테이트 풀 웹 앱 패러다임 에 더 적합하기 때문 입니다. 따라서 쿠키 메커니즘은 Ember.js 앱을 빌드 할 때 가장 좋은 방법은 아닙니다.

내 답변이 귀하의 질문에 더 많은 의미를 부여하기를 바랍니다.

---

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에 취약합니다. 사이트 간 요청 위조로부터 사이트를 보호하려면 추가 조치를 구현해야합니다.
  • 모든 단일 요청에 대해 전송됩니다 (인증이 필요없는 요청에 대해서도).

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

---

• 토큰은 어딘가에 저장해야합니다 (로컬 / 세션 스토리지 또는 쿠키)

• 토큰은 쿠키처럼 만료 될 수 있지만 더 많은 제어 권한이 있습니다

• 로컬 / 세션 저장소가 도메인간에 작동하지 않습니다. 마커 쿠키를 사용하십시오.

• Preflight requests will be sent on each CORS request

• When you need to stream something, use the token to get a signed request

• It's easier to deal with XSS than XSRF

• The token gets sent on every request, watch out its size

• If you store confidential info, encrypt the token

• JSON Web Tokens can be used in OAuth

• Tokens are not silver bullets, think about your authorization use cases carefully

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

---

I believe that there is some confusion here. The significant difference between cookie based authentication and what is now possible with HTML5 Web Storage is that browsers are built to send cookie data whenever they are requesting resources from the domain that set them. You can't prevent that without turning off cookies. Browsers do not send data from Web Storage unless code in the page sends it. And pages can only access data that they stored, not data stored by other pages.

So, a user worried about the way that their cookie data might be used by Google or Facebook might turn off cookies. But, they have less reason to turn off Web Storage (until the advertisers figure a way to use that as well).

So, that's the difference between cookie based and token based, the latter uses Web Storage.

---

Token based authentication is stateless, server need not store user information in the session. This gives ability to scale application without worrying where the user has logged in. There is web Server Framework affinity for cookie based while that is not an issue with token based. So the same token can be used for fetching a secure resource from a domain other than the one we are logged in which avoids another uid/pwd authentication.

Very good article here:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

---

One of the primary differences is that cookies are subject to Same Origin Policy whereas tokens are not. This creates all kinds of down stream effects.

Since cookies are only sent to and from a particular host that host must bear the burden of authenticating the user and the user must create an account with security data with that host in order to be verifiable.

Tokens on the other hand are issued and are not subject to same origin policy. The issuer can be literally anybody and it is up to the host to decide which issuers to trust. An issuer like Google and Facebook is typically well trusted so a host can shift the burden of authenticating the user (including storing all user security data) to another party and the user can consolidate their personal data under a specific issuer and not have to remember a bunch of different passwords for each host they interact with.

This allows for single sign on scenarios that reduce overall friction in the user experience. In theory the web also becomes more secure as specialised identity providers emerge to provide auth services instead of having every ma and pa website spinning up their own, likely half baked, auth systems. And as these providers emerge the cost of providing secure web resources for even very basic resources trends towards zero.

So in general tokens reduce the friction and costs associated with providing authentication and shifts the burden of the various aspects of a secure web to centralised parties better able to both implement and maintain security systems.

---

Use Token when...

Federation is desired. For example, you want to use one provider (Token Dispensor) as the token issuer, and then use your api server as the token validator. An app can authenticate to Token Dispensor, receive a token, and then present that token to your api server to be verified. (Same works with Google Sign-In. Or Paypal. Or Salesforce.com. etc)

Asynchrony is required. For example, you want the client to send in a request, and then store that request somewhere, to be acted on by a separate system "later". That separate system will not have a synchronous connection to the client, and it may not have a direct connection to a central token dispensary. a JWT can be read by the asynchronous processing system to determine whether the work item can and should be fulfilled at that later time. This is, in a way, related to the Federation idea above. Be careful here, though: JWT expire. If the queue holding the work item does not get processed within the lifetime of the JWT, then the claims should no longer be trusted.

Cient Signed request is required. Here, request is signed by client using his private key and server would validate using already registered public key of the client.

참고URL : https://stackoverflow.com/questions/17000835/token-authentication-vs-cookies