简介

我们了解一些基本的认证方式如下。

基础认证：简单但效率低、安全性差，适用于HTTPS环境。
会话认证：更安全，通过Cookie和会话ID管理，但不适用于多域和效率要求高的场景。
令牌和JWT认证：兼顾简单和安全。

1 用户认证 User Authentication

我们需要更新API权限，也称为授权。在本章我们将实现身份验证，这是用户可以注册的过程，新用户的登录登出控制等.

传统的整体式Django网站认证中，认证更为简单，涉及基于会话的Cookie模式，我们将在下面进行回顾。但是使用API会有些棘手。

需要注意的是，HTTP是无状态协议，因此没有内置的方式可以记住用户是否从一个请求到下一个请求进行了身份验证。每次用户请求受限资源时，必须验证自己。

2 基础认证 Base Authentication

之前发送批准的身份验证凭据授予访问权限。 大致交互流程如下：

1). 客户端发起HTTP请求
2). 服务器使用HTTP响应进行响应，该HTTP响应包含401（未授权）状态代码和WWW-Authenticate HTTP标头，其中包含有关如何授权的详细信息
3). 客户端通过Authorization HTTP标头发送回凭据
4). 服务器检查凭据并以200 OK或403 Forbidden状态代码响应

批准访问后，客户端将发送带有Authorization HTTP标头的所有以后的请求证书。图示过程如下：

    Client                                                Server
    GET / HTTP/1.1 ---->
                                          <--------HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic
    GET / HTTP/1.1 
       Authorization:   Basic d3N2OnBhc3N3b3JkMTIz 
                       ------------->
                                                  <------ HTTP/1.1 200 OK

请注意，发送的授权凭证是未加密的，
如: wsv:password123的base64编码后为 d3N2OnBhc3N3b3JkMTIz.

这种方法的主要优点是简单。但是有几个主要缺点。

首先，对于每个单个请求，服务器都必须查找并验证用户名和密码，效率低下。

最好先查找一次，然后传递一些令牌表示该用户已获批准的一种。

其次，用户凭据以明文形式传递，而不是通过互联网完全加密。这是非常不安全的，任何未加密的互联网数据都可以轻松被抓取和使用。

最后，这种方法 通常用于https加密传输 。

3 会话认证 Session Authentication

Django使用会话和Cookie的组合认证。在较高级别上，客户端使用其身份验证凭据（用户名&密码），然后从存储的服务器接收会话ID作为Cookie。然后，此会话ID将在以后的每个HTTP请求的标头中传递。

传递会话ID后，服务器将使用它来查找包含所有内容的会话对象给定用户的可用信息，包括凭据。
这种方法是有状态的，因为必须在两台服务器（会话对象）和客户端（会话ID）。

基本流程如下：

1，用户键入登录凭据（用户名，密码）。

2，服务器校验凭据是否正确并生产一个会话对象 并 存储在数据库。

3，服务器发送客户端 会话ID，并不是session 对象本身，sessin本身作为cookie存储在浏览器。

4，将来所有 此会话的请求，其HTTP header都将包含 session ID， 如果经数据库校验通过，请求将被允许。

5，一旦用户登出一个应用，会话ID将被同时在服务器和客户端摧毁。

6，如果用户稍后再次登录，新的会话将产生并作为 cookie 存储在客户端。

Django_REST_Framework中的默认设置实际上是使用Django的 身份验证和会话身份验证组合。 session ID通过后将在HTTP header中传递于每一个请求。

• 优点是，由于用户凭据仅发送一次，因此它更加有效和安全。

    并非在每个请求/响应周期中都像基本身份验证中那样。 
    服务器不必每次都验证用户的凭据，只需匹配会话ID到快速查找的会话对象。
  

• 缺点是， 首先，会话ID仅在登录已执行的浏览器中有效；它不能跨多个域工作。

     这是一个明显的问题，当一个API需要支持多个前端很麻烦，例如网站和移动应用程序。
     第二，会话对象必须保持最新，这在具有多个站点的大型站点中可能是一个挑战。您如何在每个服务器上保持会话对象的准确性？
     第三，对于每个单独的请求，即使是不需要身份验证的请求，都会发送Cookie 效率低下。
  通常不建议对任何API使用基于会话的身份验证方案，如果将有多个前端，网页和APP。
  

4 小结

用户认证的解决方案在每个项目中可以选择不同的方式，通常是在HTTP请求中传递唯一的标识符。

我们已创建用于注册，登录和注销的API端点。
但是标识符的形式不是公认的方法，它可能需要多个形式。 Django REST Framework随附了四个不同的内置身份验证选项：基本，会话，令牌和默认值。

而且还有更多的第三方软件包可提供额外的JSON Web令牌（JWT）等功能。
审查每种方法的弊端，然后为我们的Blog接口做出明智的选择。