Блог

Я пытался ознакомиться с OAUTH2, поскольку я разработал API, который я хочу защитить. Я экспериментировал с использованием JWT токенов, но хотел бы создать прототип реализации OAuth2. Проблема, с которой я сталкиваюсь (помимо аутентификации и авторизации), заключается в grant_types . Мой API будет использоваться несколькими различными способами

• Внутренние приложения (консольные приложения для интеграции и веб-приложения / настольные приложения в зависимости от варианта использования).
• Внешние приложения (как веб-, так и настольные / собственные приложения).

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

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

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

Я рассматривал возможность разделения API, но я бы предпочел один шлюз. Другим соображением может быть изменение типа гранта для каждого клиента, чтобы интеграции и пользователи обрабатывались по-разному, но я не уверен.

Мы будем признательны за любую помощь или совет, которые может предложить это замечательное сообщество. Спасибо.

Лучше всего настроить вашу систему так, чтобы она принимала оба client_credential Authorization Code (with PKCE) потока и.

client_credentials будет использоваться при входе в систему.

Authorization Code (with PKCE) для пользователей.

Вы можете добавить области / утверждения / группы или другие атрибуты к токену, чтобы предоставить доступ к ресурсу.

Если вы правильно настроили это, оба механизма будут работать одинаково.

Resource Owner Password Credentials является устаревшим потоком и не рекомендуется.

Как указывает Auth0:

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