Khung công tác Django REST Tìm kiếm Trước Kế tiếp GitHub

Xác thực

Cách xác thực được xác định

Thiết lập sơ đồ xác thực
Phản hồi trái phép và bị cấm
Cấu hình cụ thể của mod_wsgi Apache
Tham chiếu API

Xác thực cơ bản

Xác thực mã thông báo
Phiên xác thực
Xác thực người dùng từ xa
Xác thực tùy chỉnh

Ví dụ
Gói của bên thứ ba

django-rest-knox
Bộ công cụ Django OAuth
OAuth khung Django REST
Xác thực mã thông báo web JSON
Xác thực HTTP Hawk
Xác thực chữ ký HTTP
Djoser
django-rest-auth / dj-rest-auth
drf-xã hội-oauth2

xác thực.py

Xác thực

“
Auth cần phải có khả năng cắm được.
- Jacob Kaplan-Moss, "Các phương pháp tồi tệ nhất về REST"

Xác thực là cơ chế liên kết một yêu cầu đến với một tập hợp thông tin xác thực nhận dạng, chẳng hạn như
người dùng gửi yêu cầu hoặc mã thông báo mà yêu cầu đó được ký. Sau đó, các chính sách về quyền và điều
chỉnh có thể sử dụng các thông tin xác thực đó để xác định xem yêu cầu có được phép hay không.

Khung REST cung cấp một số lược đồ xác thực ngay lập tức và cũng cho phép bạn triển khai các lược đồ tùy
chỉnh.

Quá trình xác thực luôn chạy ngay từ đầu chế độ xem, trước khi diễn ra quá trình kiểm tra quyền và điều tiết
cũng như trước khi bất kỳ mã nào khác được phép tiếp tục.

Thuộc request.user tính thường sẽ được đặt thành một phiên bản của lớp contrib.auth của gói User .

Thuộc request.auth tính được sử dụng cho bất kỳ thông tin xác thực bổ sung nào, ví dụ: nó có thể được sử
dụng để thể hiện mã thông báo xác thực mà yêu cầu đã được ký.
Lưu ý: Đừng quên rằng bản thân việc xác thực sẽ không cho phép hoặc không cho phép một yêu cầu gửi đến
, nó chỉ xác định thông tin xác thực mà yêu cầu được thực hiện.

Để biết thông tin về cách thiết lập chính sách cấp phép cho API của bạn, vui lòng xem tài liệu về quyền .

Cách xác thực được xác định

Các sơ đồ xác thực luôn được định nghĩa là một danh sách các lớp. Khung REST sẽ cố gắng xác thực với
từng lớp trong danh sách, đồng thời sẽ đặt request.user và request.auth sử dụng giá trị trả về của lớp
đầu tiên xác thực thành công.

Nếu không có lớp nào xác thực, request.user nó sẽ được đặt thành một phiên bản của
django.contrib.auth.models.AnonymousUser , và request.auth sẽ được đặt thành None .

Giá trị của request.user và request.auth đối với các yêu cầu chưa được xác thực có thể được sửa đổi
bằng cách sử dụng cài đặt UNAUTHENTICATED_USER và UNAUTHENTICATED_TOKEN .

Thiết lập sơ đồ xác thực

Các lược đồ xác thực mặc định có thể được đặt trên toàn cầu bằng cách sử dụng cài
DEFAULT_AUTHENTICATION_CLASSES đặt. Ví dụ.

REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': [
'rest_framework.authentication.BasicAuthentication',
'rest_framework.authentication.SessionAuthentication',
]
}

Bạn cũng có thể đặt lược đồ xác thực trên cơ sở mỗi chế độ xem hoặc mỗi chế độ xem bằng cách sử dụng
chế APIView độ xem dựa trên lớp.

from rest_framework.authentication import SessionAuthentication, BasicAuthentication

from rest_framework.permissions import IsAuthenticated
from rest_framework.response import Response
from rest_framework.views import APIView

class ExampleView(APIView):
authentication_classes = [SessionAuthentication, BasicAuthentication]
permission_classes = [IsAuthenticated]

def get(self, request, format=None):

content = {
'user': str(request.user), # `django.contrib.auth.User` instance.
'auth': str(request.auth), # None
}
return Response(content)
Hoặc nếu bạn đang sử dụng @api_view trình trang trí với các chế độ xem dựa trên chức năng.

@api_view(['GET'])
@authentication_classes([SessionAuthentication, BasicAuthentication])
@permission_classes([IsAuthenticated])
def example_view(request, format=None):
content = {
'user': str(request.user), # `django.contrib.auth.User` instance.
'auth': str(request.auth), # None
}
return Response(content)

Phản hồi trái phép và bị cấm

Khi một yêu cầu chưa được xác thực bị từ chối cấp phép, có hai mã lỗi khác nhau có thể phù hợp.

HTTP 401 trái phép

Quyền HTTP 403 bị từ chối

Phản hồi HTTP 401 phải luôn bao gồm WWW-Authenticate tiêu đề hướng dẫn khách hàng cách xác thực.
Phản hồi HTTP 403 không bao gồm WWW-Authenticate tiêu đề.

Loại phản hồi sẽ được sử dụng tùy thuộc vào sơ đồ xác thực. Mặc dù có thể sử dụng nhiều sơ đồ xác thực
nhưng chỉ có thể sử dụng một sơ đồ để xác định loại phản hồi. Lớp xác thực đầu tiên được đặt trên dạng
xem được sử dụng khi xác định loại phản hồi .

Lưu ý rằng khi một yêu cầu có thể xác thực thành công nhưng vẫn bị từ chối cấp phép thực hiện yêu cầu,
trong trường hợp đó, phản 403 Permission Denied hồi sẽ luôn được sử dụng, bất kể sơ đồ xác thực.

Cấu hình cụ thể của mod_wsgi Apache

Lưu ý rằng nếu triển khai lên Apache bằng mod_wsgi , tiêu đề ủy quyền sẽ không được chuyển tới ứng dụng
WSGI theo mặc định, vì người ta cho rằng xác thực sẽ được xử lý bởi Apache, thay vì ở cấp ứng dụng.

Nếu bạn đang triển khai lên Apache và sử dụng bất kỳ xác thực không dựa trên phiên nào, bạn sẽ cần định
cấu hình rõ ràng mod_wsgi để chuyển các tiêu đề bắt buộc tới ứng dụng. Điều này có thể được thực hiện
bằng cách chỉ định WSGIPassAuthorization lệnh trong ngữ cảnh thích hợp và đặt nó thành 'On' .

# this can go in either server config, virtual host, directory or .htaccess

WSGIPassAuthorization On

Tham chiếu API

Xác thực cơ bản
Lược đồ xác thực này sử dụng Xác thực cơ bản HTTP , được ký dựa trên tên người dùng và mật khẩu của
người dùng. Xác thực cơ bản thường chỉ thích hợp để thử nghiệm.
Nếu được xác thực thành công, BasicAuthentication hãy cung cấp thông tin xác thực sau.

request.user sẽ là một User phiên bản Django.

request.auth sẽ là None .

Các phản hồi không được xác thực bị từ chối cấp phép sẽ dẫn đến HTTP 401 Unauthorized phản hồi có
tiêu đề WWW-Authenticate thích hợp. Ví dụ:

WWW-Authenticate: Basic realm="api"

Lưu ý: Nếu sử dụng BasicAuthentication trong sản xuất, bạn phải đảm bảo rằng API của bạn chỉ khả
dụng trên https . Bạn cũng nên đảm bảo rằng ứng dụng khách API của bạn sẽ luôn yêu cầu lại tên người
dùng và mật khẩu khi đăng nhập và sẽ không bao giờ lưu trữ những chi tiết đó vào bộ lưu trữ liên tục.

Xác thực mã thông báo

Lưu ý: Xác thực mã thông báo do khung Django REST cung cấp là cách triển khai khá đơn giản.

Để biết cách triển khai cho phép nhiều mã thông báo cho mỗi người dùng, có một số chi tiết triển khai bảo
mật chặt chẽ hơn và hỗ trợ hết hạn mã thông báo, vui lòng xem gói bên thứ ba Django REST Knox .

Lược đồ xác thực này sử dụng lược đồ Xác thực HTTP dựa trên mã thông báo đơn giản. Xác thực mã thông
báo thích hợp cho các thiết lập máy khách-máy chủ, chẳng hạn như máy tính để bàn gốc và máy khách di
động.

Để sử dụng TokenAuthentication lược đồ này, bạn cần phải định cấu hình các lớp xác thực để bao gồm
TokenAuthentication và đưa thêm rest_framework.authtoken vào cài đặt của mình
INSTALLED_APPS :

INSTALLED_APPS = [
...
'rest_framework.authtoken'
]

Đảm bảo chạy manage.py migrate sau khi thay đổi cài đặt của bạn.

Ứng dụng này rest_framework.authtoken cung cấp khả năng di chuyển cơ sở dữ liệu Django.

Bạn cũng sẽ cần tạo mã thông báo cho người dùng của mình.

from rest_framework.authtoken.models import Token

token = Token.objects.create(user=...)
print(token.key)

Để khách hàng xác thực, khóa mã thông báo phải được đưa vào Authorization tiêu đề HTTP. Khóa phải
được bắt đầu bằng chuỗi ký tự "Mã thông báo", với khoảng trắng ngăn cách hai chuỗi. Ví dụ:
 Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b

Nếu bạn muốn sử dụng một từ khóa khác trong tiêu đề, chẳng hạn như Bearer , chỉ cần phân lớp
TokenAuthentication và đặt keyword biến lớp.

Nếu được xác thực thành công, TokenAuthentication hãy cung cấp thông tin xác thực sau.

request.user sẽ là một User phiên bản Django.

request.auth sẽ là một rest_framework.authtoken.models.Token ví dụ.

Các phản hồi không được xác thực bị từ chối cấp phép sẽ dẫn đến HTTP 401 Unauthorized phản hồi có
tiêu đề WWW-Authenticate thích hợp. Ví dụ:

WWW-Authenticate: Token

Công curl cụ dòng lệnh có thể hữu ích để kiểm tra các API được xác thực bằng mã thông báo. Ví dụ:

curl -X GET http://127.0.0.1:8000/api/example/ -H 'Authorization: Token 9944b09199c62

Lưu ý: Nếu sử dụng TokenAuthentication trong sản xuất, bạn phải đảm bảo rằng API của bạn chỉ khả
dụng trên https .

Tạo mã thông báo

Bằng cách sử dụng tín hiệu
Nếu bạn muốn mọi người dùng đều có Mã thông báo được tạo tự động, bạn chỉ cần bắt post_save tín hiệu
của Người dùng.

from django.conf import settings

from django.db.models.signals import post_save
from django.dispatch import receiver
from rest_framework.authtoken.models import Token

@receiver(post_save, sender=settings.AUTH_USER_MODEL)
def create_auth_token(sender, instance=None, created=False, **kwargs):
if created:
Token.objects.create(user=instance)

Lưu ý rằng bạn sẽ muốn đảm bảo đặt đoạn mã này vào models.py mô-đun đã cài đặt hoặc một số vị trí
khác sẽ được Django nhập khi khởi động.

Nếu bạn đã tạo một số người dùng, bạn có thể tạo mã thông báo cho tất cả người dùng hiện tại như thế này:
 from django.contrib.auth.models import User
from rest_framework.authtoken.models import Token

for user in User.objects.all():

Token.objects.get_or_create(user=user)

Bằng cách hiển thị điểm cuối api

Khi sử dụng TokenAuthentication , bạn có thể muốn cung cấp cơ chế để khách hàng nhận được mã thông
báo được cung cấp tên người dùng và mật khẩu. Khung REST cung cấp chế độ xem tích hợp để cung cấp
hành vi này. Để sử dụng nó, hãy thêm chế độ obtain_auth_token xem vào URLconf của bạn:

from rest_framework.authtoken import views

urlpatterns += [
path('api-token-auth/', views.obtain_auth_token)
]

Lưu ý rằng phần URL của mẫu có thể là bất cứ thứ gì bạn muốn sử dụng.

Chế obtain_auth_token độ xem sẽ trả về phản hồi JSON khi hợp lệ username và password các trường
được ĐĂNG tới chế độ xem bằng dữ liệu biểu mẫu hoặc JSON:

{ 'token' : '9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b' }

Lưu ý rằng chế obtain_auth_token độ xem mặc định sử dụng rõ ràng các yêu cầu và phản hồi JSON, thay
vì sử dụng các lớp trình phân tích cú pháp và trình kết xuất mặc định trong cài đặt của bạn.

Theo mặc định, không có quyền hoặc điều chỉnh nào được áp dụng cho chế obtain_auth_token độ xem.
Nếu bạn muốn áp dụng điều chỉnh, bạn sẽ cần ghi đè lớp chế độ xem và đưa chúng vào bằng
throttle_classes thuộc tính.

Nếu bạn cần một phiên bản tùy chỉnh của chế độ obtain_auth_token xem, bạn có thể làm như vậy bằng
cách phân lớp ObtainAuthToken lớp chế độ xem và thay vào đó sử dụng phiên bản đó trong conf url của
bạn.

Ví dụ: bạn có thể trả về thông tin người dùng bổ sung vượt quá token giá trị:

from rest_framework.authtoken.views import ObtainAuthToken

from rest_framework.authtoken.models import Token
from rest_framework.response import Response

class CustomAuthToken(ObtainAuthToken):

def post(self, request, *args, **kwargs):

serializer = self.serializer_class(data=request.data,
context={'request': request})
serializer.is_valid(raise_exception=True)
user = serializer.validated_data['user']
 token, created = Token.objects.get_or_create(user=user)
return Response({
'token': token.key,
'user_id': user.pk,
'email': user.email
})

Và trong urls.py :

urlpatterns += [
path('api-token-auth/', CustomAuthToken.as_view())
]

Với quản trị viên Django

Cũng có thể tạo Token theo cách thủ công thông qua giao diện quản trị. Trong trường hợp bạn đang sử dụng
cơ sở người dùng lớn, chúng tôi khuyên bạn nên vá TokenAdmin lớp để tùy chỉnh nó theo nhu cầu của mình,
cụ thể hơn bằng cách khai báo trường user là raw_field .

your_app/admin.py :

from rest_framework.authtoken.admin import TokenAdmin

TokenAdmin.raw_id_fields = ['user']

Sử dụng lệnh quản lý Django

Kể từ phiên bản 3.6.4, có thể tạo mã thông báo người dùng bằng lệnh sau:

./manage.py drf_create_token <username>

lệnh này sẽ trả về mã thông báo API cho người dùng nhất định, tạo mã thông báo đó nếu nó không tồn tại:

Generated token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b for user user1

Trong trường hợp bạn muốn tạo lại mã thông báo (ví dụ: nếu nó đã bị xâm phạm hoặc bị rò rỉ), bạn có thể
chuyển một tham số bổ sung:

./manage.py drf_create_token -r <username>

Phiên xác thực

Lược đồ xác thực này sử dụng phần phụ trợ phiên mặc định của Django để xác thực. Xác thực phiên phù hợp
với các máy khách AJAX đang chạy trong cùng bối cảnh phiên với trang web của bạn.
Nếu được xác thực thành công, SessionAuthentication hãy cung cấp thông tin xác thực sau.

request.user sẽ là một User phiên bản Django.

request.auth sẽ là None .

Phản hồi không được xác thực bị từ chối cấp phép sẽ dẫn đến HTTP 403 Forbidden phản hồi.

Nếu bạn đang sử dụng API kiểu AJAX với SessionAuthentication, bạn cần đảm bảo rằng bạn bao gồm mã
thông báo CSRF hợp lệ cho bất kỳ lệnh gọi phương thức HTTP "không an toàn" nào, chẳng hạn như ,
PUT hoặc yêu cầu. Xem tài liệu Django CSRF để biết thêm chi tiết. PATCH POST DELETE

Cảnh báo : Luôn sử dụng chế độ xem đăng nhập tiêu chuẩn của Django khi tạo trang đăng nhập. Điều này sẽ
đảm bảo lượt xem đăng nhập của bạn được bảo vệ đúng cách.

Xác thực CSRF trong khung REST hoạt động hơi khác so với Django tiêu chuẩn do cần hỗ trợ cả xác thực dựa
trên phiên và không dựa trên phiên cho cùng một chế độ xem. Điều này có nghĩa là chỉ những yêu cầu được
xác thực mới yêu cầu mã thông báo CSRF và các yêu cầu ẩn danh có thể được gửi mà không cần mã thông
báo CSRF. Hành vi này không phù hợp với chế độ xem đăng nhập, vốn phải luôn được áp dụng xác thực CSRF.

Xác thực người dùng từ xa

Lược đồ xác thực này cho phép bạn ủy quyền xác thực cho máy chủ web của mình, máy chủ này sẽ đặt
REMOTE_USER biến môi trường.

Để sử dụng nó, bạn phải có django.contrib.auth.backends.RemoteUserBackend (hoặc một lớp con)

trong AUTHENTICATION_BACKENDS cài đặt của mình. Theo mặc định, RemoteUserBackend tạo User đối
tượng cho tên người dùng chưa tồn tại. Để thay đổi hành vi này và hành vi khác, hãy tham khảo tài liệu Django
.

Nếu được xác thực thành công, RemoteUserAuthentication hãy cung cấp thông tin xác thực sau:

request.user sẽ là một User phiên bản Django.

request.auth sẽ là None .

Tham khảo tài liệu trên máy chủ web của bạn để biết thông tin về cách định cấu hình phương thức xác thực,
ví dụ:

Cách thực hiện xác thực Apache

NGINX (Hạn chế quyền truy cập)

Xác thực tùy chỉnh

Để triển khai sơ đồ xác thực tùy chỉnh, hãy phân lớp BaseAuthentication và ghi đè
.authenticate(self, request) phương thức. Phương thức này sẽ trả về hai bộ (user, auth) nếu xác
thực thành công hoặc None ngược lại.

Trong một số trường hợp thay vì quay lại None , bạn có thể muốn đưa ra một
AuthenticationFailed ngoại lệ khỏi .authenticate() phương thức.

Thông thường, cách tiếp cận bạn nên thực hiện là:

Nếu không thử xác thực, hãy trả về None . Bất kỳ chương trình xác thực nào khác cũng đang được sử
dụng sẽ vẫn được kiểm tra.
Nếu xác thực được cố gắng nhưng không thành công, hãy đưa ra một AuthenticationFailed ngoại lệ.
Phản hồi lỗi sẽ được trả về ngay lập tức, bất kể mọi kiểm tra quyền và không kiểm tra bất kỳ sơ đồ xác
thực nào khác.
Bạn cũng có thể ghi đè .authenticate_header(self, request) phương thức này. Nếu được triển khai,
nó sẽ trả về một chuỗi sẽ được sử dụng làm giá trị của WWW-Authenticate tiêu đề trong HTTP 401
Unauthorized phản hồi.

Nếu .authenticate_header() phương thức không bị ghi đè, sơ đồ xác thực sẽ trả về HTTP 403
Forbidden phản hồi khi yêu cầu không được xác thực bị từ chối truy cập.

Lưu ý: Khi trình xác thực tùy chỉnh của bạn được gọi bởi các thuộc tính .user hoặc .auth đối tượng yêu
cầu, bạn có thể thấy tệp AttributeError được nâng cấp lại dưới dạng tệp WrappedAttributeError .
Điều này là cần thiết để ngăn chặn ngoại lệ ban đầu bị chặn bởi quyền truy cập thuộc tính bên ngoài. Python
sẽ không nhận ra rằng AttributeError nguồn gốc từ trình xác thực tùy chỉnh của bạn và thay vào đó sẽ
cho rằng đối tượng yêu cầu không có thuộc tính .user or .auth . Những lỗi này phải được sửa hoặc xử lý
bởi người xác thực của bạn.

Ví dụ
Ví dụ sau sẽ xác thực mọi yêu cầu đến với tư cách là người dùng do tên người dùng cung cấp trong tiêu đề
yêu cầu tùy chỉnh có tên 'X-USERNAME'.

from django.contrib.auth.models import User

from rest_framework import authentication
from rest_framework import exceptions

class ExampleAuthentication(authentication.BaseAuthentication):
def authenticate(self, request):
username = request.META.get('HTTP_X_USERNAME')
if not username:
return None

try:
user = User.objects.get(username=username)
except User.DoesNotExist:
raise exceptions.AuthenticationFailed('No such user')

return (user, None)

Gói của bên thứ ba

Các gói bên thứ ba sau đây cũng có sẵn.

django-rest-knox
Thư viện Django-rest-knox cung cấp các mô hình và chế độ xem để xử lý xác thực dựa trên mã thông báo
theo cách an toàn và mở rộng hơn so với sơ đồ TokenAuthentication tích hợp sẵn - lưu ý đến Ứng dụng một
trang và ứng dụng di động. Nó cung cấp mã thông báo cho mỗi khách hàng và các chế độ xem để tạo chúng
khi được cung cấp một số xác thực khác (thường là xác thực cơ bản), để xóa mã thông báo (cung cấp đăng
xuất được thực thi bởi máy chủ) và xóa tất cả mã thông báo (đăng xuất tất cả các ứng dụng khách mà người
dùng đã đăng nhập vào ).

Bộ công cụ Django OAuth

Gói Bộ công cụ OAuth Django cung cấp hỗ trợ OAuth 2.0 và hoạt động với Python 3.4+. Gói này được
jazzband duy trì và sử dụng OAuthLib tuyệt vời . Gói này được ghi chép đầy đủ và được hỗ trợ tốt và hiện là
gói được đề xuất của chúng tôi để hỗ trợ OAuth 2.0 .

Cài đặt và cấu hình

Cài đặt bằng cách sử dụng pip .

pip install django-oauth-toolkit

Thêm gói vào INSTALLED_APPS và sửa đổi cài đặt khung REST của bạn.

INSTALLED_APPS = [
...
'oauth2_provider',
]

REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': [
'oauth2_provider.contrib.rest_framework.OAuth2Authentication',
]
}

Để biết thêm chi tiết, hãy xem khung Django REST - Tài liệu bắt đầu .

OAuth khung Django REST

Gói OAuth của khung Django REST cung cấp cả hỗ trợ OAuth1 và OAuth2 cho khung REST.

Gói này trước đây được đưa trực tiếp vào khung REST nhưng hiện được hỗ trợ và duy trì dưới dạng gói của
bên thứ ba.

Cài đặt và cấu hình

Cài đặt gói bằng pip .

pip install djangorestframework-oauth

Để biết chi tiết về cấu hình và cách sử dụng, hãy xem tài liệu OAuth của khung REST Django để xác thực và
cấp quyền .
Xác thực mã thông báo web JSON
Mã thông báo Web JSON là một tiêu chuẩn khá mới có thể được sử dụng để xác thực dựa trên mã thông báo.
Không giống như sơ đồ TokenAuthentication tích hợp sẵn, Xác thực JWT không cần sử dụng cơ sở dữ liệu để
xác thực mã thông báo. Gói xác thực JWT là djangorestframework-simplejwt cung cấp một số tính năng cũng
như ứng dụng danh sách đen mã thông báo có thể cắm được.

Xác thực HTTP Hawk

Thư viện HawkREST được xây dựng trên thư viện Mohawk để cho phép bạn làm việc với các yêu cầu và phản
hồi đã được Hawk ký trong API của bạn. Hawk cho phép hai bên liên lạc với nhau một cách an toàn bằng
cách sử dụng các tin nhắn được ký bằng khóa chung. Nó dựa trên xác thực truy cập HTTP MAC (dựa trên các
phần của OAuth 1.0 ).

Xác thực chữ ký HTTP

Chữ ký HTTP (hiện là bản nháp của IETF ) cung cấp một cách để đạt được xác thực nguồn gốc và tính toàn
vẹn của tin nhắn cho các tin nhắn HTTP. Tương tự như sơ đồ Chữ ký HTTP của Amazon , được nhiều dịch vụ
của Amazon sử dụng, nó cho phép xác thực theo yêu cầu, không trạng thái. Elvio Toccalino duy trì gói
djangorestframework-httpssignature (lỗi thời) cung cấp cơ chế Xác thực Chữ ký HTTP dễ sử dụng. Bạn có thể
sử dụng phiên bản nhánh cập nhật của djangorestframework-httpssignature , đó là drf-httpsig .

Djoser
Thư viện Djoser cung cấp một tập hợp các khung nhìn để xử lý các hành động cơ bản như đăng ký, đăng
nhập, đăng xuất, đặt lại mật khẩu và kích hoạt tài khoản. Gói hoạt động với mô hình người dùng tùy chỉnh và
sử dụng xác thực dựa trên mã thông báo. Đây là bản triển khai REST sẵn sàng để sử dụng của hệ thống xác
thực Django.

django-rest-auth / dj-rest-auth
Thư viện này cung cấp một tập hợp các điểm cuối API REST để đăng ký, xác thực (bao gồm xác thực phương
tiện truyền thông xã hội), đặt lại mật khẩu, truy xuất và cập nhật thông tin người dùng, v.v. Bằng cách có các
điểm cuối API này, các ứng dụng khách của bạn như AngularJS, iOS, Android và các ứng dụng khác có thể
giao tiếp độc lập với trang web phụ trợ Django của bạn thông qua API REST để quản lý người dùng.

Hiện tại có hai nhánh của dự án này.

Django-rest-auth là dự án ban đầu nhưng hiện không nhận được bản cập nhật .
Dj-rest-auth là một nhánh mới hơn của dự án.

drf-xã hội-oauth2
Drf-social-oauth2 là một khung giúp bạn xác thực với các nhà cung cấp oauth2 xã hội lớn, chẳng hạn như
Facebook, Google, Twitter, Orcid, v.v. Nó tạo mã thông báo theo cách JWTed với thiết lập dễ dàng.

drf không cần mật khẩu

drfpasswordless bổ sung hỗ trợ không cần mật khẩu ( lấy cảm hứng từ Medium, Square Cash) cho sơ đồ
TokenAuthentication của Django REST Framework. Người dùng đăng nhập và đăng ký bằng mã thông báo
được gửi đến điểm liên hệ như địa chỉ email hoặc số điện thoại di động.

django-rest-authemail
django-rest-authemail cung cấp giao diện API RESTful để đăng ký và xác thực người dùng. Địa chỉ email được
sử dụng để xác thực chứ không phải tên người dùng. Điểm cuối API có sẵn để đăng ký, xác minh email đăng
ký, đăng nhập, đăng xuất, đặt lại mật khẩu, xác minh đặt lại mật khẩu, thay đổi email, xác minh thay đổi email,
thay đổi mật khẩu và chi tiết người dùng. Một dự án ví dụ đầy đủ chức năng và hướng dẫn chi tiết được bao
gồm.

Django-Rest-Durin
Django-Rest-Durin được xây dựng với ý tưởng có một thư viện xác thực mã thông báo cho nhiều ứng dụng
khách API Web/CLI/Mobile thông qua một giao diện nhưng cho phép cấu hình mã thông báo khác nhau cho
mỗi Ứng dụng khách API sử dụng API. Nó cung cấp hỗ trợ nhiều mã thông báo cho mỗi người dùng thông qua
các mô hình, chế độ xem, quyền tùy chỉnh hoạt động với Django-Rest-Framework. Thời gian hết hạn mã thông
báo có thể khác nhau đối với mỗi ứng dụng khách API và có thể tùy chỉnh thông qua Giao diện quản trị
Django.

Thông tin thêm có thể được tìm thấy trong Tài liệu .

Tài liệu được xây dựng bằng MkDocs .