你对Web容器常规session的描述不太精确。首先浏览器cookie存的那个session标识一般是sessionid(一般web容器好像会在前面加prefix，不然JSESSIONID，PHPSESSIONID，这样并不好。)，正常情况下它不需要对称加密(实际上它和对称加密的那个也不是一个东西)，只要保证当前唯一性就OK，服务器端的session存储是一个key-value结构，客户cookie存的那个sessionid它标明了客户端浏览器的唯一性，也是服务器端这个session key-value存储结构的key。这个session value又是个容器，你可以往里面再天添加key-value结构存储，比如seesion.set("userid",1)这样的语句就在服务器端标明了当前登录用户是1号用户。
服务器端的这个Session存储有内存式，比如Java容器里面的非简单对象，有文件式，我记得PHP可以设置成这样，有RDB数据库式，django默认就是这样，有Redis缓存式，Django可以很轻松切换成这种方式，Tomcat也可以切换成这种，顺便解决了跨实例的Session共享问题，不过好多Javaer搞这个都表示搞这个很费劲。
至于你说的客户端对称加密session cookie，这只是前几年单机内存紧张时，某些大站变相存储跨服务的session cache信息的办法，这几年有了redis，好像用的很少了，要不就转成明文+签名的方式了。
至于你说的token，token是api或者app的鉴权方法，它和Web网站开发的容器常规session基本没有任何关系。它只是API两端约定好的鉴权数据传递方式。
Web session也不一定用于鉴权，它在web领域最典型的案例用法是购物车。说白了Session是回话，它的核心作用是唯一性的标识客户端的那个浏览器环境。
至于楼主说的SPA的鉴权问题，底层实现上是依靠浏览器cookie的sessionid，上层代码里面如何搞，很简单，借鉴restful api方式，就是服务器端收到越权数据请求时返回401\403这类的权限拒绝信息，然后Angular里面对$http添加Interceptor，碰到这类权限拒绝信息直接给用户报个"需要登录"，然后SPA本身转向到login cotroller or page就ok了。
注意:鉴权问题必须是服务器端来判定。
ps:心态老了，越来越不喜欢参加争论和回答问题了。
【 在 facilitator 的大作中提到: 】
: 我做的是nodejs全栈 原理是一样的 你问这种问题 我估计你可能对http的cookie和session的原理缺乏基本的
【 在 facilitator 的大作中提到: 】
: 我做的是nodejs全栈 原理是一样的 你问这种问题 我估计你可能对http的cookie和session的原理缺乏基本的了解 跟java或者angular都没半毛钱关系
: auth信息是通过对server的http请求回叫来读取的
: 首先auth信息是藏在cookie当中的加密字段 （你cookie当中个加密字段叫做session 那么它就是所谓的session了 当然你定义成别的名字也无所谓） 通常存的是一个经过对称加密的、在server端有一定时限的token 用户登录之后生成这个token颁发给客户端 因为存在了cookie当中 会随着每次http请求发到server
: ...................
--
修改:dhcn FROM 123.120.255.*
FROM 123.120.255.*