Каков правильный поток кода авторизации OAuth2? - PullRequest
0 голосов
/ 03 августа 2020

В настоящее время я не знаком с потоком кода авторизации OAuth2.0, я прочитал много статей об этом, и в настоящее время я все еще не знаю, как правильно его реализовать. Итак, что я знаю о потоке:

  1. Пользователь входит в систему с использованием OAuth
  2. Пользователь перенаправлен на сервер авторизации для кода авторизации
  3. Обратный вызов для разрешения / scope
  4. Перенаправлен на сервер авторизации для токена доступа в обмен на код авторизации
  5. Перенаправлен обратно клиенту с токеном доступа
  6. Клиент использует токен доступа для доступа к серверу ресурсов.

Прямо сейчас я все еще не понимаю, где должна проходить проверка логина (логин имени пользователя - пароль)? Это отдельная проверка перед переходом к потоку OAuth, и как только пользователь станет действительным, он должен go вернуться в поток?

Ответы [ 3 ]

0 голосов
/ 04 августа 2020

Обычное решение - экстернализация как OAuth 2.0, так и Open Id Connect из вашего кода с помощью зрелой библиотеки безопасности. Когда вы новичок в этом типе безопасности, вам придется учиться. Мои ресурсы дадут вам представление о том, как все это сочетается:

Библиотеки, которые вы интегрируете, зависят от используемого вами технологического стека. Приведенные выше ресурсы относятся к одностраничному приложению и NodeJS API.

0 голосов
/ 10 августа 2020

У меня есть ресурсы, которые объясняют OAuth 2.0 на примере входа Google . Позвольте мне попытаться перефразировать это в соответствии с вашим вопросом.

Давайте возьмем пример входа пользователя в Интерком с помощью «Войти через Google».

  1. Пользователь нажимает кнопку «Войти через Google». Это приведет к перенаправлению на конечную точку провайдера идентификации /authorize (может быть разным для каждого провайдера), которая go - на их страницу входа.
  2. Пользователь перенаправляется на страницу учетных записей Google. Если вы еще не вошли в систему, пользователь может ввести здесь свой адрес электронной почты Google / пароль .
  3. Google перенаправляет обратно в Интерком с помощью authorization_code (например, перенаправляет на https://intercom.com/authcallback?code=XYZ... )
  4. Внутренний сервер интеркома отправляет это authorization_code с client_id и client_secret (из своего проекта в Google) и получает access_token (обычно в конечную точку /token)
  5. Интерком может затем использовать access_token для доступа к профилю пользователя из Google.

Итак, чтобы ответить на ваш вопрос, пользователь может ввести свой адрес электронной почты / пароль на странице поставщика OAuth. . Имейте в виду, что OAuth 2.0 не указывает, как провайдер аутентифицирует пользователя . Это означает, что провайдер OAuth может аутентифицировать своих пользователей разными способами, такими как электронная почта / пароль, email magi c -ссылка, SMS OTP , и c. Предполагается, что ваш веб-сайт просто доверяет провайдеру OAuth в том, что он правильно аутентифицирует пользователя для вас.

Некоторые дополнительные ресурсы, которые помогут вам лучше понять OAuth 2.0:

0 голосов
/ 03 августа 2020

авторизация авторизации пришла (логин имени пользователя - пароль)?

OAuth 2.0 НЕ протокол аутентификации

OAuth 2.0 спецификация определяет протокол делегирования

Любое использование имени пользователя и пароля выходит за рамки OAuth 2.0, и вам следует обратить внимание на Open ID Connect, который представляет собой протокол аутентификации, построенный на основе OAuth 2.0.

Лучшая практика для потока кода авторизации - использовать PKCE на OAuth или OpenID Connect.

...