Oauth 2.0 и OpenId Connect для аутентификации и авторизации REST API - PullRequest
0 голосов
/ 04 марта 2020

После прочтения книг и просмотра видео на OAuth, OID C, PKCE, JWT и др. c. Я до сих пор не знаю, как использовать все это для моего приложения (защищенный REST API).

Мой пример использования довольно прост. Я хочу, чтобы мои пользователи могли войти в систему с помощью Google, Amazon, Okta или чего-то еще, и единственная информация, которую я хочу получить от них, - это адрес электронной почты, который они использовали для входа, и ничего больше. После первого входа в систему их электронная почта будет добавлена ​​в базу данных, и в отдельном процессе я предоставлю им некоторые разрешения (к каким ресурсам они могут получить доступ).

Итак, давайте представим стандартный поток кода авторизации и давайте перенесемся вперед к части токена доступа. URI перенаправления был вызван, мы находимся в моем клиенте (где-то мой backend / API), где я получаю токен доступа. На данный момент пользователь успешно прошел аутентификацию.

Но что теперь?

  • Меня больше не волнует Google (нужен ли мне токен доступа?), Но я все еще хочу проверить, может ли пользователь использовать мой API для каждого запроса и может ли он обращаться к ресурсам API в зависимости от его разрешений.
  • Как сохранить аутентификацию пользователя (только для 2-часовых периодов) и проверить его разрешения ? Повар сеанса ie, токен или что-то еще со сроком действия?
  • Нужен ли мне собственный сервер авторизации для проверки, имеет ли пользователь доступ к запрашиваемому ресурсу?
  • Учитывая мои требования, нужно ли мне PKCE, если к API обращаются из SPA или мобильного приложения? Разве не будет достаточным поток кода авторизации - SPA или мобильное приложение получат код авторизации, а затем вызовут конечную точку обратного вызова из API?

И более важный вопрос: я задаю правильные вопросы или я совершенно не в курсе, и это не так, как это должно работать?

1 Ответ

0 голосов
/ 05 марта 2020

С точки зрения ваших вопросов:

  • Вашему API необходим токен доступа для каждого запроса
  • Для управления сеансом без сохранения состояния отправляется маркер доступа для каждого запроса
  • Рекомендуется использовать свой собственный Сервер авторизации, который управляет перенаправлением на социальных провайдеров - это упростит ваши пользовательские интерфейсы и API, которые должны обрабатывать только один тип токенов - это также означает, что вы контролируете токены, которые используют ваши приложения
  • Да - используйте PKCE для публикуемых c клиентов - это решит для вас сервер авторизации и библиотеки безопасности UI

Ваш вариант использования совсем не прост на техническом уровне и требует много понимания. Хорошей отправной точкой является понимание этих аспектов:

  • Роль пользовательского интерфейса и как выглядит кодированное решение
  • Роль сервера авторизации и его конфигурация
  • Роль API и как выглядит закодированное решение
  • Используются сообщения Open Id Connect

Эти ссылки могут быть полезны для просмотра:

При наличии маркера доступа и пользовательский интерфейс, и API могут получить электронное письмо через шаг 12 во второй ссылке для поиска информации о пользователе.

...