Блог

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

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

Я думаю, что тип предоставления учетных данных клиента — лучший способ.

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

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

Вопрос 2. Для чего используются идентификатор клиента и секрет клиента?

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

Вопрос 4: Если я предоставляю им токен доступа без идентификатора клиента и секрета, нормально ли иметь бесконечное время истечения? и

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

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

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

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

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

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

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

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

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

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

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

Вопрос 2. Для чего используются идентификатор клиента и секрет клиента?

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

Фактически это имя пользователя и пароль в этом сценарии.

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

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

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

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