Случай использования OpenID Connect

Question

Недавно я обнаружил стандарт OpenID Connect, и теперь я изо всех сил пытаюсь найти правильный способ его использования.

Итак, скажем, я создаю довольно стандартное веб-приложение, которое должно иметь понятие аутентифицированного пользователя. Таким образом, мое первое намерение - создать локальную БД с пользовательской таблицей, содержащую идентификатор пользователя, электронную почту, сначала & фамилию, пароль, соль и т. Д. Это означает, что мне нужно реализовать все соответствующие функции, такие как регистрация, вход, изменение/забыть пароль и т. д.

Вместо этого я предпочитаю использовать соединение OpenID и использовать информацию о пользователе, хранящуюся в другом месте (например, в Google).

Тогда я могу выполнить обычную магию OAuth2, чтобы перенаправить пользователя, попросить согласия и так далее.

Начиная с этого момента я как бы теряю трек. После того, как Google (или любой другой AS) вернул мой токен ID приложения с базовыми данными пользователя (адрес электронной почты, имя, телефон) , что мне с ним делать? Должен ли я по-прежнему иметь локальную пользовательскую БД (без пароля), заполненную этими полями? В этом случае OpenID Connect - это просто автоматическая процедура регистрации? А как насчет сеансов и выхода из системы, что делать, если пользователь меняет свой телефон на сайте Google, пока я все еще сохраняю старую версию?

Я читал много статей OpenID Connect в Интернете, но все они, похоже, описывают основные потоки при получении токена, поэтому я смущен насчет дальнейших этапов.

Я бы очень признателен за любые советы и рекомендации по этим проблемам.

Answer 1

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

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

---

^Q1Должен ли я до сих пор локальный пользователь БД (без пароля), населенного из этих полей?

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

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

---

^Q2(Если мне нужно дублировать почти всю информацию в моей базе данных) OpenID Connect просто фантазии автоматическая процедура регистрации до?

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

---

^Q3насчет сессий и лог-аута?

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

Если вы хотите синхронизированный сеанс, так что пользователь будет активен только в вашем приложении, в то время как у него также есть сеанс в стороннем провайдере, тогда у вас есть больше работы. См., Если вы еще этого не сделали, OpenID Connect Session Management 1.0 для получения дополнительной информации.

---

^Q4Что делать, если пользователь изменяет свой телефон на сайте Google, а я до сих пор он сохранил старую версию?

Это не проблема, потому что если вы не использовали OpenID Connect и должны были управлять идентификаторами пользователей конкретного приложения, у вас была бы такая же проблема. Пользователь будет менять свой телефон в Google и, если он также не будет активно менять телефон в своем приложении, он будет устаревшим.

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

---

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

Если вы считаете, что вам нужно лучше контролировать процесс аутентификации, чем то, что даст вам поставщик социальной проверки подлинности, есть еще возможность пойти с более гибким провайдером, Auth0 приходит на ум, но я смещен ( Я инженер Auth0 ). Этот тип опции даст вам больше контроля, все еще беря на себя ответственность за внедрение стандартов проверки подлинности вашей спины.