Как реализовать OAuth, когда ресурс и серверы аутентификации совпадают

Question

У меня есть Django Rest API с аутентификацией JWT, который является бэкэндом для Angular-интерфейса.Есть много клиентов, которые используют сервис с нашим веб-интерфейсом.Теперь некоторые корпоративные клиенты хотели интегрировать API из серверной части своей системы.Я не хочу удалять JWT из текущих API.Я планирую создать новые API в том же бэкэнде с токеном OAuth для этих пользователей.

Интересно, как лучше реализовать OAuth для этого сценария.

Я думаю, что тип предоставления Client Credentials - это лучший способ.

Вопрос 1. Прав ли я, что учетные данные клиента - это правильный подход?

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

Вопрос 2: Что такое использование идентификатора клиента и его секрета?

Вопрос 3. Должен ли мой бэкэнд скрыть процесс генерации идентификатора клиента и секрета клиента и просто дать токен доступа (или) присвоить им идентификатор клиента и секрет клиента и затем попросить сгенерировать токен доступа?

Вопрос 4: Если я даю им Access Token без идентификатора клиента и секрета, хорошо ли иметь бесконечный срок действия?и

TLDR;Как реализовать OAuth, когда сервер ресурсов и сервер аутентификации совпадают ?

Answer 1

Вопрос1: Прав ли я, что учетные данные клиента - это правильный подход?

Да.Предоставление новых API не должно вызываться в контексте конечного пользователя.

Вопрос 2: Как используется идентификатор клиента и секрет клиента?

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

В этом сценарии это, по сути, имя пользователя и пароль.

Вопрос3: должен ли мой сервер скрыть процесс создания идентификатора клиентаи Client secret и просто дайте токен доступа (или) дайте им Client ID и Client Secret и попросите затем сгенерировать токен доступа?

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

Answer 2

В oAuth2 есть 4 типа предоставления, которые предназначены для разных сценариев.

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

Учетные данные для пароля владельца ресурса (ROPC): потребитель (приложение) выполняет вызовы с использованием токена носителя, созданного с использованием apikey, secret, username и password. В основном используется, когда вы (ваш сервер авторизации) уже знаете пользователей (база данных пользователей обрабатывается в вашей собственной системе).

Код авторизации: потребитель (приложение) совершает вызовы с использованием токена на предъявителя, созданного с использованием кода авторизации. Код авторизации предоставляется третьей стороной (которая фактически имеет / управляет зарегистрированными данными пользователя) и созданным кодом авторизации, связанным с зарегистрированным пользователем. Вход в Google и Facebook для различных сайтов является типичным примером. Facebook / Google предоставляет код авторизации для этих сайтов, и они обменивают этот код на токен.

Неявное предоставление: сочетание пароля и кода авторизации. Вместо кода авторизации вы получаете токен на предъявителя со стороннего сервера авторизации.

Вопрос 1: Прав ли я, что учетные данные клиента - это правильный подход? Я думаю, что вы можете использовать CC, если в вашем бэкэнде нет логики уровня пользователя. Если задействован пользовательский уровень, может быть ROPC - лучший выбор

Вопрос 2: Для чего используется идентификатор клиента и секрет клиента? Идентификатор клиента и секрет клиента очень похожи на имя пользователя и пароль на уровне приложения, который используется для получения токена канала-носителя.

Вопрос3: Должен ли мой сервер скрыть процесс генерации идентификатора клиента и секрета клиента и просто дать токен доступа (или) присвоить им идентификатор клиента и секрет клиента и затем попросить сгенерировать токен доступа? Если вы используете oAuth2, ваш потребитель должен создать токен доступа. Но, глядя на ваш вариант использования, может быть даже достаточно простого хэша userId + timestamp. ;)

Answer 3

1. authorization code грант или implicit грант могут быть более подходящими для этого сценария. Первый позволяет вам добавить шаг аутентификации до того, как токены будут возвращены пользователям (это может быть полезно, если вы хотите интегрировать аутентификацию JWT также и в это), а второй в основном используется для одностраничных приложений и выполняет не включает промежуточный этап аутентификации. Это было бы полезно, если вы хотите повысить эффективность.
2. client_id и client_secret выдаются вам при регистрации клиентского приложения в вашем провайдере идентификации (сервере авторизации). Это клиентское приложение означает не приложение или API, принадлежащие вашим клиентам, а ваше собственное приложение, в которое вы планируете включить OAuth (и OIDC). Эти два параметра полезны при выполнении запросов на авторизацию для получения токенов. Сервер использует эти значения, чтобы определить, сделан ли запрос допустимым приложением. Только у вас есть доступ к этим значениям, так как вы будете тем, кто регистрирует приложение на сервере.
3. Я думаю, что на этот вопрос дан ответ в предыдущем разделе.

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