Session-based Authentication VS Token-based Authentication
2016-08-12 10:36
381 查看
In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie)
and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id-String. It is just an identifier and the server does everything
else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database). It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security concern and more importantly
it can do and change all of this on the fly. Furthermore it can log the users every move on the website(s). Possible disadvantages are bad scale-ability (especially over more than one server farm) and extensive memory usage.
In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request
(It can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked
after each request made by the client to the server. There are a number of ways to use/ create tokens:
a) using a hash mechanism e.g. HMAC-SHA1
--id and expiry_id are sent in plaintext with the resulting hash attached (k is only know to the server)
b) encrypting the token symmetrically e.g. with AES
--x represents the en-/decryption key
c) encrypting it asymmetrically e.g. with RSA
Productive systems are usually more complex than those two archetypes. Amazon for example uses both mechanisms on its website. Also hybrids can be used to issue tokens as described in 2 and also associate
a user session with it for user tracking or possible revocation and still retain the client flexibility of classic tokens. Also OAuth 2.0 uses short-lived and specific bearer-tokens and longer-lived refresh tokens e.g. to get bearer-tokens.
Sources:
https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-tokenlibraries/http://stackoverflow.com/questions/1283594/securing-cookie-based-authenticationhttps://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vstoken/
Demystifying Web Authentication (Stateless Session Cookies) stateless-session-cookieshttps://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id-String. It is just an identifier and the server does everything
else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database). It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security concern and more importantly
it can do and change all of this on the fly. Furthermore it can log the users every move on the website(s). Possible disadvantages are bad scale-ability (especially over more than one server farm) and extensive memory usage.
In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request
(It can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked
after each request made by the client to the server. There are a number of ways to use/ create tokens:
a) using a hash mechanism e.g. HMAC-SHA1
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
--id and expiry_id are sent in plaintext with the resulting hash attached (k is only know to the server)
b) encrypting the token symmetrically e.g. with AES
token = AES(user_id|expiry_date, x)
--x represents the en-/decryption key
c) encrypting it asymmetrically e.g. with RSA
token = RSA(user_id|expiry_date, private key)
Productive systems are usually more complex than those two archetypes. Amazon for example uses both mechanisms on its website. Also hybrids can be used to issue tokens as described in 2 and also associate
a user session with it for user tracking or possible revocation and still retain the client flexibility of classic tokens. Also OAuth 2.0 uses short-lived and specific bearer-tokens and longer-lived refresh tokens e.g. to get bearer-tokens.
Sources:
https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-tokenlibraries/http://stackoverflow.com/questions/1283594/securing-cookie-based-authenticationhttps://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vstoken/
Demystifying Web Authentication (Stateless Session Cookies) stateless-session-cookieshttps://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
相关文章推荐
- The Ins and Outs of Token Based Authentication
- Forms Authentication Timeout vs Session Timeout
- SharePoint中的Form Based Authentication VS Windows Authentication
- Token Based Authentication
- Claims Based Authentication and Token Based Authentication和WIF
- Forms authentication timeout vs sessionState timeout
- Token Based Authentication in Web API 2
- SharePoint中的Form Based Authentication VS Windows Authentication
- Asp.Net MVC webAPI Token based authentication
- SharePoint中的Form Based Authentication VS Windows Authentication
- username and password authentication vs client certificate based authentication
- Qt: Session management error: None of the authentication protocols specified are supported
- Token ,Cookie和Session的区别--学习笔记
- JPA EntityManagerFactory Vs Hibernate' SessionFactory
- UsernamePasswordAuthenticationToken
- Statement-based vs Row-based Replication
- Session ID/session token 及和cookie区别
- CAS 4.0 Cluster / Tomcat redis Session manager / Token(TGT)存入Redis集群 / Nginx 负载
- SharePoint 2013自定义Providers在基于表单的身份验证(Forms-Based-Authentication)中的应用
- app与后台的token、sessionId、RSA加密登录认证与安全解决方案