OpenID Connect - используйте OpenID Provider для аутентификации существующей системы учетных записей

Question

Я пытался исследовать, но не нашел ничего полезного, но, возможно, я не знаю, что искать.

Задание

Мне необходимо настроить URL-адрес обратного вызова OpenID Connect для предоставления настраиваемому поставщику OpenID.

Фон

Перед любым входом в систему мы заполняем нашу базу данных учетными записями третьих лиц. Затем отправьте электронные письма для сбора данных для каждой учетной записи позже через взаимодействие с пользовательскими формами в нашей системе.

На стороннем веб-сайте есть учетные записи, которые, как я полагаю, предоставлены их ОП. В нашей системе есть учетные записи, которые создаются путем извлечения их учетных записей через API и создания их локально в нашей системе (этот процесс не может измениться).

Они хотят отправить пользователя со своего веб-сайта на наш с помощью единого входа через OpenID Connect.

Что делать

Теперь я понимаю, как настроить конечную точку, которая получает токен и что ее необходимо отправить обратно с «прямым обратным каналом», чтобы получить понятный идентификатор токена (из чтения документов OpenID).

Полагаю, проще всего было бы сравнить токен с тем, что мы собрали через API, который определяет каждую уникальную учетную запись пользователя (например, UUID их учетных записей). Я не знаю, что доступно из токена ID. После того, как я выяснил, какая учетная запись пытается аутентифицироваться / войти, я могу программно аутентифицироваться через нашу систему и перенаправить на соответствующую страницу.

Это правдоподобно? - кажется хакерским, поскольку это, кажется, игнорирует все, что предоставляет OpenID Connect?

Answer 1

Они хотят отправить пользователя со своего сайта на наш с помощью единого входа через OpenID Connect.

Как я понимаю из вашего объяснения, вам нужно разрешить доступ к вашей системе для пользователей, которые размещены (хранятся) на стороннем сервере авторизации.

Это похоже на сценарий «Войти через Facebook» или «Войти через Google». По сути, вы извлекаете пользовательские данные из надежного провайдера идентификации (сервер авторизации AKA) и создаете пользователя в своей системе. Если у вашей третьей стороны есть провайдер идентификации, который становится доступным для вашей системы и позволяет вашей системе использовать что-то похожее на «Войти в систему с помощью X», то вы можете приступить к реализации этого. И когда вы получаете идентификационный токен от логина, вы можете сравнить его значение с ранее извлеченными пользовательскими данными. Для этого вы можете использовать что-то вроде идентификатора пользователя, электронной почты или просто идентификатора, понятного для обеих систем.

Что касается единого входа, если системы работают в браузере и пользователь уже вошел в систему, пользователь может не требовать повторного входа в систему при нажатии «Войти в систему с X». Что похоже на использование логина Google.