#jwt #openid-connect
#jwt #OpenID-connect
Вопрос:
Недавно я обнаружил стандарт OpenID Connect и теперь пытаюсь найти правильный способ его использования.
Итак, допустим, я создаю довольно стандартное веб-приложение, которое должно иметь представление об аутентифицированном пользователе. Итак, мое первое намерение — создать локальную базу данных с таблицей пользователей, содержащую идентификатор пользователя, адрес электронной почты, имя и фамилию, пароль, соль и т. Д. Это означает, что мне нужно реализовать все соответствующие функции, такие как регистрация, вход, изменение / забывание пароля и т.д.
Вместо этого я выбираю использование OpenID connect и использую информацию о пользователях, хранящуюся в другом месте (например, в Google).
Затем я могу выполнить обычную магию OAuth2, чтобы перенаправить пользователя, запросить согласие и так далее.
Начиная с этого момента я как бы теряю трек. После того, как Google (или что-то еще) вернул в мой серверный идентификатор приложения токен с базовой информацией о пользователе (адрес электронной почты, имя, телефон), что мне с ним делать? Должна ли у меня все еще быть локальная база данных пользователя (без пароля), заполненная из этих полей? В этом случае OpenID Connect — это просто причудливая процедура автоматической регистрации? А как насчет сеансов и выходов из системы, что, если пользователь поменяет свой телефон на сайте Google, пока у меня все еще сохранена старая версия?
Я читал много статей OpenID Connect в Интернете, но все они, похоже, описывают основные процессы получения токена, поэтому я не понимаю дальнейших этапов.
Я был бы очень признателен за любые подсказки / советы по этим проблемам.
Ответ №1:
Я бы согласился с вами, что наиболее интересным аспектом этих современных схем аутентификации является то, что вы легко делегируете аутентификацию стороннему поставщику и не обременены необходимостью писать и поддерживать весь этот шаблонный, но очень чувствительный код для управления идентификаторами пользователей.
Что касается ваших вопросов «что будет дальше», давайте подходить к ним один за другим; Я постараюсь не начинать каждый ответ с it depends.
Q1 Должен ли я по-прежнему иметь локальную базу данных пользователя (без пароля), заполненную из этих полей?
Это зависит от того, если вашему приложению не нужно знать о пользовательской информации, когда пользователь не взаимодействует с приложением в Сети, тогда вам может сойти с рук почти ничего не хранить. В лучшем случае вы хотите сохранить уникальный идентификатор пользователя для данных, которые создает пользователь.
С другой стороны, если ваше приложение уведомляет пользователя по электронной почте, когда происходит что-то (действительно) интересное, вам необходимо сохранить электронную почту пользователя в своей базе данных.
Q2 (Если мне нужно дублировать почти всю информацию в моей базе данных) OpenID Connect — это просто необычная процедура автоматической регистрации?
Отчасти, просто будучи стандартом, который позволяет вам делегировать проверку подлинности вашего приложения сторонней стороне, вы уже получили огромные преимущества от его существования. Аутентификация не является тривиальной, если вы можете передать это кому-то другому, сделайте это. Делая это, вы также оказываете услугу конечному пользователю, потому что (в зависимости от популярности выбранного вами провайдера) теперь он может войти в ваше приложение без необходимости запоминать еще один набор учетных данных.
Q3 Как насчет сеансов и выходов из системы?
Здесь нет существенных изменений, если вы хотите независимый сеанс. Раньше ваше приложение проверяло учетные данные и запускало сеанс, теперь оно проверяет токен, который может быть предоставлен сторонним поставщиком, а затем запускает сеанс. Выход из системы просто завершит ваш сеанс.
Если вам нужен синхронизированный сеанс, чтобы пользователь был активен только в вашем приложении, пока у него также есть сеанс у стороннего поставщика, тогда вам предстоит проделать больше работы. Смотрите, если вы еще этого не сделали, OpenID Connect Управление сеансами 1.0 для получения дополнительной информации.
Q4 Что делать, если пользователь меняет свой телефон на сайте Google, в то время как у меня все еще сохранена старая версия?
Это не проблема, потому что, если бы вы не использовали OpenID Connect и должны были управлять идентификаторами пользователей, зависящими от приложения, у вас была бы та же проблема. Пользователь сменил бы свой телефон в Google, и если бы он также не изменил телефон в вашем приложении, он был бы устаревшим.
Как указал фиддур, существует также возможность предварительной проверки у поставщика на наличие обновленной информации. Это то, что поддерживает большинство провайдеров, и имеет побочные преимущества, которые также могут обеспечить хорошее взаимодействие с конечным пользователем.
В заключение, если у вас есть возможность делегировать аутентификацию внешнему поставщику, пожалуйста, сделайте это. Внедрение собственной пользовательской аутентификации или даже утверждение себя в качестве поставщика аутентификации, соответствующего всем доступным стандартам, является очень трудоемкой задачей, сопряженной с проблемами безопасности.
Если вы считаете, что вам нужно лучше контролировать процесс аутентификации, чем то, что вам может предоставить поставщик социальной аутентификации, все еще есть возможность выбрать более гибкого поставщика, на ум приходит Auth0, но я предвзят (я инженер Auth0 ). Этот тип опции даст вам больше контроля, при этом вы все равно возьмете на себя бремя внедрения стандартов аутентификации.
Комментарии:
1. Q2: Это также дает пользователю возможность единого входа, особенно если другие провайдеры также будут предлагать динамическую регистрацию OpenID Connect.
2. Q4: Существует также возможность регулярной повторной проверки userinfo у поставщика, поэтому пользователю не нужно обновлять одну и ту же информацию на всех сайтах.
3. @fiddur, это правда, для конечного пользователя есть значительные преимущества. Я обновлю эти два пункта, чтобы упомянуть выгоды с точки зрения пользователя. Спасибо.
4. Спасибо, ребята, теперь это имеет гораздо больше смысла. Я думаю, я просто не смотрел на это под правильным углом.