Как провайдер OpenID аутентифицирует конечного пользователя?

OpenID Connect 1.0 позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, и предоставляет утверждения в обмен на токен доступа. Маркер доступа предоставляется /user_info или /me конечной точке, чтобы получить взамен запрошенные утверждения.

Раздел 3.1.2.3 в Спецификация OpenID Connect 1.0 объясняет процесс аутентификации конечного пользователя. Однако в нем четко говорится

Методы, используемые сервером авторизации для аутентификации конечного пользователя (например, имя пользователя и пароль, файлы cookie сеанса и т. Д.), Выходят за рамки данной спецификации.

Реализация этих методов и есть мой вопрос. Кроме того, спецификация OAuth2.0 также не предоставляет никакой информации о реализации.

У меня есть сомнения в том, как аутентифицировать конечного пользователя? Возможные случаи, о которых я мог подумать, следующие:

  1. Мы храним некоторые данные пользователя, такие как информация о его профиле, имя пользователя, пароль, на сервере авторизации и другую информацию, связанную с пользователем, на сервере ресурсов.
  2. Мы храним все на сервере ресурсов и проверяем учетные данные пользователя, отправляя POST запрос вместе с учетными данными пользователя во внутренний API отдыха на сервере ресурсов.
  3. Сервер авторизации и ресурсов использует один и тот же экземпляр БД и, следовательно, не имеет вызовов API.

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

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

Допустим, я пытаюсь написать свою собственную реализацию OpenId Connect. Какие предложения вы бы дали мне для аутентификации конечных пользователей?

Я попытался просмотреть базу кода библиотеки node-oidc-provider, но библиотека не не аутентифицирует пользователя и пропускает эту часть. Было бы очень полезно, если бы кто-нибудь мог дать какие-либо указания по этому поводу. Какой должна быть лучшая практика? Какие методы использует любой другой поставщик OpenID?


oauth-2.0 openid-connect openid-provider
person Kartik Chauhan    schedule 20.11.2019    source источник
comment
Как вы уже поняли, аутентификация пользователя полностью выходит за рамки OpenID Connect или OAuth. Таким образом, вы можете делать это как хотите.   -  person Robby Cornelissen    schedule 20.11.2019
comment
Это именно то, о чем я прошу. Как мне это сделать? Какие лучшие практики? Что мне нужно учитывать при его реализации?   -  person Kartik Chauhan    schedule 20.11.2019
comment
Что ж, поскольку это не имеет ничего общего с OpenID Connect или OAuth, ваш вопрос в основном сводится к следующему: «Как мне аутентифицировать пользователя?», Что довольно широко. Одно но: реализация аутентификации на сервере ресурсов полностью лишает смысла использование OpenID Connect.   -  person Robby Cornelissen    schedule 20.11.2019
comment
Таким образом, отменяется второй пункт, который заключается в аутентификации на сервере ресурсов с использованием REST API.   -  person Kartik Chauhan    schedule 20.11.2019

Ответы (1)


arrow_upward
1
arrow_downward

Как видно из полезного изображения, из статьи о Архитектура OpenId / OAuth 2.0 из статьи Такахико Кавасаки на Medium

Oid / oauth2.0 auth

Есть причина, по которой механизмы аутентификации явно заявлены как выходящие за рамки, поскольку аутентификация и ее требования реализуются совершенно отдельными средствами. Это можно сделать с помощью абсолютно любого механизма аутентификации, который вы выберете, единственное требование - аутентификация для реализации правильных ответов на запросы OpenID / OAuth.

Допустим, вы хотите, чтобы страница аутентифицировалась в вашей Active Directory. Все, что вам нужно сделать, это расширить существующую систему Active Directory с помощью соответствующих плагинов OAuth и OpenID (при условии, что они есть), настроить их, и после того, как эти протоколы станут доступны для аутентификации и авторизации, вы можете указать свой AD в качестве поставщика OpenID / OAuth для всех готов принять их.

Еще в ранние дни OpenID, когда сайты, такие как LiveJournal, впервые разрешили произвольным поставщикам OpenID проходить аутентификацию, для проверки идеи я сделал имитирующую страницу OpenID на своем хобби-веб-сервере, у которого было достаточно поддержки OpenID для аутентификации отдельного пользователя с помощью пароль я там вручную указал. Сработало нормально, но, вероятно, это был бы довольно крайний пример. В наши дни проще использовать Google OpenID connect или аналогичный инструмент для централизованного управления профилями.

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

Обратите внимание, что OAuth позволяет аутентифицированному пользователю находиться на месте водителя, что обычно имеет место для общедоступных веб-приложений.

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

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

person Gnudiff    schedule 20.11.2019