カイカイ、あなたはクッキーとセッション認証を話す最後の時間は、私は本当にインタビューに会いました
どのように結果は？
結果インタビュアーは、より良い方法があると私に尋ねましたか？
あなたがハングアップしているようです
、悲しいああ黙れ。最終的に物事のは良い方法はありませんか？
思いますか？
セッションとクッキー認証について知っているあなたによって前の一般的には、既に、セッション認証サーバはとても近代的なWebアプリケーションが認定ソリューションで、お客様に、より傾斜しており、一貫性とセッション情報を格納するセッションを確保するために多くの作業を行う必要がありますエンド方向、クッキー認証は、クライアントの方法に基づいておりますが、クッキーの欠点も明らかにされ、最後には欠点が何であるかのいずれかの記事にジャンプすることができます。より折衷的なアプローチではありそれ？一部
我々は、認証情報がクライアントに保存することができ、認証情報のセキュリティ問題を解決するため、サーバーを完全認定状況なので、アップサーバー拡張機能が便利なようにできている場合、クライアントに保存された認証情報は、重要な点は、検証の安全性でありますたくさん。セキュリティソリューションの情報は、一般的な方法は、シグネチャベースの機構上の認証用公開マイクロチャネルインタフェースとして、署名機構である今です。
署名、情報の送信者だけが、デジタル文字列の一部を生産する数字のこの文字列だけでなく、有効な証明の送信者情報の信憑性にメッセージを送信するために偽造することはできません他の人。
ユーザーが正常に認証が成功した後のシステムと効果的に着陸すると、サーバーは、文字列トークンを生成するためのメカニズムのいくつかの種類を使用しますが、このトークンは、送信元IPの下、顧客、有効期限、利用者の情報は、この文字列には、例えば、多くの情報を含めることができます最後は、クライアント後の各要求は、Cookieまたは他の手段のいずれかによっては、することができ、実際には、運ぶために非常に無料の方法を、このトークンを持っているが、サーバーはコンセンサスができなければなりません。もちろん、ここで私はクッキーをお勧めしません。サーバは（ソースIP、有効期限やその他の情報を確認できます）撤回認証トークンのリクエストを受信すると、有効な場合に動作することが許可されています。
トークンベースの認証は、現代のインターネット認証方法は、一般的に、それは利点が何を持っていることを使用されていますか？
1.サポートクロスドメインアクセスは、クッキーは、ユーザ認証情報がHTTPヘッダを送信を介して送信することを設け、存在しないトークン機構にあるドメインへのアクセスを崩壊させることができます。
2. 无状态:Token机制在服务端不需要存储session信息，因为Token自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
3. 解耦 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
4. 适用性更广：只要是支持http协议的客户端，就可以使用token认证。
5. 服务端只需要验证token的安全，不必再去获取登录用户信息，因为用户的登录信息已经在token信息中。
6. 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python,PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
那基于token的认证方式有哪些缺点呢？
1. 网络传输的数据量增大：由于token中存储了大量的用户和安全相关的信息，所以比单纯的cookie信息要大很多，传输过程中需要消耗更多流量，占用更多带宽，
2. 和所有的客户端认证方式一样，如果想要在服务端控制token的注销有难度，而且也很难解决客户端的劫持问题。
3. 由于token信息在服务端增加了一次验证数据完整性的操作，所以比session的认证方式增加了cpu的开销。
但是整体来看，基于token的认证方式还是比session和cookie方式要有很大优势。在所知的token认证中，jwt是一种优秀的解决方案
JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。
头部
header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。
{
"alg": "HS256",
"typ": "JWT"
}Payload
Payload 部分也是一个JSON对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号除了以上字段之外，你完全可以添加自己想要的任何字段，这里还是提醒一下，由于jwt的标准，信息是不加密的，所以一些敏感信息最好不要添加到json里面
{
"Name":"菜菜",
"Age":18
}Signature
为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥（这个秘钥只有服务端知道），签名算法是header中指定的那个，然对它们签名即可。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。需要提醒一下：base64是一种编码方式，并非加密方式。
基于token的认证方式，大体流程为：
1. 客户端携带用户的登录凭证（一般为用户名密码）提交请求
2. 服务端收到登录请求，验证凭证正确性，如果正确则按照协议规定生成token信息，经过签名并返回给客户端
3. 客户端收到token信息，可以保存在cookie或者其他地方，以后每次请求的时候都携带上token信息
4. 业务服务器收到请求，验证token的正确性，如果正确则进行下一步操作
这里再重复一次，无论是token认证，cookie认证，还是session认证，一旦别人拿到客户端的标识，还是可以伪造操作。所以采用任何一种认证方式的时候请考虑加入来源ip或者白名单，过期时间，另外有条件的情况下一定要使用https。
