Technical difference between session and token bas

问题:

Im writing my bachelors in which i need to figure out which authentication/authorization method fits best with the company i'm collaborating with.

So i've been comparing the session and token based auth methods but there are a few points that are unclear to me about how tokens work and how they are better than session authentication:

The only benefits that are 100% clear to me are that tokens can be used from clients that doesn't have a cookie store and that they can be used with different sub domains and completely separate domains because it's not prevented the browsers CORS policy.

• I read that all cookies are sent with each request to the original domain( except if a cookie is set to only be sent on a secure connection ), which would mean that a token would be present twice in a request, unless of course you authenticate users from another domain. Is this a correct assumption?
• How is a token validated serverside? After decryption, is it checked against the username, password and and secret/private key or is it only the secret/private key that is used here?
• If i need username/userID when authorizing them for a certain resource on a server i didn't authenticate them on, can i blindly trust those credentials if i don't have the original user data to check against?

Finally, many articles claim that tokens protect against CSRF.

From this article:

CSRF: We will also have protection against cross-site request forgery (CSRF). Users are susceptible to CSRF attacks since they can already be authenticated with say a banking site and this could be taken advantage of when visiting other sites."

Which makes absolutely no sense to me. It seems like he's saying that a OAuth like system prevents CSRF? I don't know a lot about how CSFR works, so it might just be me that is blank here, but as far as i understand neither sessions or tokens protect against this since neither are unique to each request.

Edit: I just realized the reason tokens may prevent CSFR is that it's not automatically sent by the browser if another site manages to submit a form to your server from your browser. But this means tokens can be susceptible if pulled from the cookie header on the server, which if you use JWT should not be a problem since it uses it's own "Authorization" header, which you must set with JS. But this still makes the scotch.io articles claim sound like nonsense to me.

回答1:

Check Cookies vs Tokens: The Definitive Guide for a good summary on the characteristics of traditional cookie-based authentication systems and the more recent token-based system.

TL;DR Tokens-based authentication is more relevant than ever. We examine the differences and similarities between cookie and token-based authentication, advantages of using tokens, and address common questions and concerns developers have regarding token-based auth.

I'm not a big fan of this exact terminology because what you actually place within a cookie can also be considered a token; most of the times it's a by-reference token that maps to some server-side data while the so called token-based authentications favors by-value tokens (JWT - Learn JSON Web Tokens) that carry the data within the token itself.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

The validation of these by-value tokens is accomplished by signatures that ensure that the token was created by the entity holding the associated key used during signing and that the contents cannot be tampered by anyone else without knowledge of the key. This premise is the foundation to trust the received tokens.

In relation to CSRF, it's true that a token-based system will mitigate this because to the contrary to what happens with cookies, the browser will not automatically send these token credentials (assumes tokens are not included in the request as cookies).

Imagine the following, application CK exposes resources protected with session cookies and application TK exposes resources protected with tokens.

User X authenticates in both applications and as such will be issued a session cookie for application CK and a token for application TK. If an attacker creates an evil site EV and tricks user X into visit it, it can perform automatic requests to both application CK and TK from within the user's browser.

However, for application CK the browser of user X will automatically include the session cookie and as such evil site EV just accessed a protected resource, while for the request to application TK the browser will not include the token automatically.