Использование стороннего сайта для потока кода авторизации OAuth2 / OIDC - понимание последних шагов

Question

У меня есть сайт, который, будем надеяться, будет использовать сторонний сервис для входа (через OAuth2 и OIDC). Я понимаю 90% вовлеченного процесса, но не могу получить то, что вижу в качестве последнего шага. Я опишу шаги, как я их вижу здесь, и, возможно, кто-то может помочь мне заполнить пробелы. В моем случае сервер ресурсов и сервер авторизации - это один и тот же компьютер.

Это процесс входа в систему, как я его себе представляю.

1. Пользователь заходит на мой сайт (назовем его Сайтом A) и нажимает кнопку входа
2. Они перенаправлены на сайт аутентификации (Сайт B), где они введите свое имя пользователя / пароль.
3. При условии правильных учетных данных они затем перенаправляются обратно на сайт А с кодом авторизации.
4. Сайт A принимает этот код авторизации и в обратном канале связывается с сайтом B снова просят обменять код на токен.
5. Сайт B предоставляет токен доступа к сайту A (не конечному пользователю, к серверу)
6. Затем сайт A снова связывается с сайтом B (серверы ресурсов и аутентификации в этом сценарии совпадают) и получают соответствующие данные пользователя.

Таким образом, пользователь проходит проверку подлинности, и мы знаем, какие у него есть претензии, однако в приведенном выше сценарии я не понимаю, как Сайт А знает, кто я (конечный пользователь).

Я никогда не входил в систему на сайте А, поэтому, по-видимому, файлы cookie не были установлены. По сути, я зашел на сайт, был перенаправлен на другой сайт, вошел в систему и затем перенаправлен обратно на сайт A, но есть ли на последнем перенаправлении файлы cookie, чтобы идентифицировать меня?

Я много читал об этом в Интернете, но не нашел четкого ответа.

Также правильно ли я считаю, что в потоке кода авторизации токен доступа никогда не попадает к пользователю, а вместо этого находится на сервере приложений?

Answer 1

Если вы really хотите знать, кто является пользователем SiteA, это должен быть пользователь из собственной пользовательской базы данных SiteA. Имеет смысл, если SiteA не просто прокси для API SiteB и имеет своих собственных пользователей, разрешения и функциональность.

Чтобы выяснить, кто является пользователем SiteA, вам необходимо сопоставить всех пользователей вашего SiteA с пользователями Auth Server.

Часть 1. Импорт существующих пользователей на Auth Server

Если вы контролируете Auth Server, импортируйте всех своих текущих пользователей в его базу данных. У каждого из них будет Subject ID (идентификатор на стороне сервера аутентификации). Скопируйте эти идентификаторы обратно соответствующим пользователям в базе данных вашего SiteA: в таблице User вашего SiteA будет новый столбец, например: ИД пользователя, имя_пользователя, имя_пользователя, user_auth_id (новый столбец)

Если вы не можете импортировать всех своих пользователей, это усложняется. Единственный способ, о котором я могу подумать: вам придется регистрировать этих пользователей дважды - один раз в OIDC-провайдере и один раз в SiteA, а затем связать пользователя SiteA с пользователем OIDC.

Часть 2. Сопоставление входящего пользователя с внутренним пользователем в SiteA

В случае успешного ответа от OIDC Server вы получите идентификационный токен. Содержит sub претензию с ИД субъекта пользователя. Когда вы получите это, вам нужно будет выполнить поиск во внутренней БД и найти соответствующего пользователя SiteA. Если вы не нашли его, создайте нового пользователя на SiteA (если все существующие пользователи были импортированы)

Как только вы узнаете, кто пользователь, войдите в систему SiteA, как вы это обычно делаете (например, дайте им cookie).

Answer 2

Серверы авторизации OpenID Connect предоставляют конечную точку userinfo , которую Сайт A может использовать для получения информации о пользователе, который авторизовал токен доступа (или код авторизации). Чтобы поставщик аутентификации (сайт B) мог это сделать, он должен поддерживать связь между токеном и его пользователем. Таким образом, для этой цели нет файла cookie.

Вы правы относительно потока кода авторизации - токен доступа остается на бэкэнде - нет необходимости отправлять его внешнему интерфейсу / пользователю.

Чтобы связать токены, хранящиеся в бэкэнде SiteA, с последующими запросами из браузера, у вас есть несколько вариантов:

• Вы можете использовать бэкэнд-сеанс с файлами cookie, что очень просто, потому что большинство фреймворков имеют встроенную поддержку. Файл cookie отправляется автоматически при каждом запросе, и токены могут быть сохранены в объекте сеанса. Это решение может быть сложнее масштабировать - если вам нужен кластер.
• Вы можете создать собственную реализацию сеанса - либо с помощью файлов cookie, либо с помощью некоторого идентификатора, ожидаемого в REST API, в качестве значения заголовка HTTP авторизации. Данные внутреннего сеанса могут храниться в некотором распределенном хранилище, например Hazelcast или базе данных. Идентификатор сеанса может быть в форме подписанного JWT, поэтому вы можете хранить в нем информацию о пользователе.