Аутентификация, авторизация пользователей и единый вход (SSO) с использованием Django

[rSedoy]

А еще в этой схеме мне не нравятся http запросы внутри views к другому серверу. При равномерных логинах проблему можно и не заметить, а вот допустим акция, в систему разом приходят условные 1к пользователей, синхронному фреймворку от этого станет плохо.

[Nireko]

В 5.0 много чего добавили

[rSedoy]

тоже хорошо, всё больше мест с async, хотя тут вызовы и не в authenticate, а я больше про этот неприятный момент, когда код views синхронный.

[OleSv]

Поправьте пожалуйста в тексте статьи Reaml на Realm.

[MyShinobi]

Спасибо)

[hwedar]

Тема заинтересовала, пожалуйста, напишите вторую часть про Access Type = Bearer-only.

[MyShinobi]

Спасибо, за обратную связь. Постараюсь опубликовать в ближайшее время.

[DonAlPAtino]

"Access Type = Bearer-only" обязательно! Пока читал хотел написать коммент, что "Access Type = Confidential" в принципе самый понятный flow. Держишь секрет на бэкенде и ОК. А вот как правильно с остальными работать - хороший вопрос.

[MyShinobi]

Постараюсь оправдать ваши ожидания)

[SeveR31]

Вопрос к автору- как использовать django_keyclock, если библиотека не поддерживает Джанго выше 4.0(проверено на Django 4.0.9) ? Есть какие-либо аналоги или остается только через allauth внедрять?
А ещё хотелось бы увидеть статью, как внедрять такую аутентификацию на уже имеющийся прод

[MyShinobi]

Честно говоря, на первый вопрос по поводу django_keyclock и Django 4 - на данный момент затрудняюсь ответить. Но в следующей публикации на эту тему я, постараюсь изучить это вопрос.
"А ещё хотелось бы увидеть статью, как внедрять такую аутентификацию на уже имеющийся прод" - спасибо, большое за обратную связь. Я подумаю над материалом с этой точки зрения.
На текущий момент, вторую часть про SSO планирую публиковать в марте.

[Smerig]

Два критических заменчания:

Одной из отличительных особенностей заключается, в том что в OpenID Connect, добавляется дополнительный шаг в работе алгоритма. Когда вместо access token, сначала провайдер SSO возвращает клиенту code. В обмен на который у провайдера SSO клиент получается access token.

Этот шаг всегда был в старом добром OAuth 2.0.

Кроме приведенных вами трёх Authorization Flow есть как минимум еще один, довольно интересный: Direct Access Grant flow. Это когда мы в провайдер ПОСТ запросом можем отправить user credentials (username, password), а получить access token.

А еще для мобильных клиентов, десктопных клиентов и SPA есть Authorization Code Flow with PKCE.