У меня есть пара бэкэнд API, которые являются проектами Django.У них есть пользовательский интерфейс (одностраничное приложение) и логин, основанный на пароле имени пользователя.
Мои клиенты обычно являются разработчиками и им не нужен пользовательский интерфейс, все, что им нужно, - это доступ к бэкэнд-API иони могут создавать свои собственные панели мониторинга и т. д. Они хотели бы интегрировать API-интерфейсы с бэкэнд-системой.
Вопросы
вопрос 1. Кажется, я планирую использовать набор инструментов django-oauth-toolмне, что тип предоставления учетных данных клиента будет подходящим для этого варианта использования.Я прав?
Для эксперимента я запустил отдельный oauth-сервер, локально работающий на порту 8000, запустил сервер ресурсов (r1) на 8001 и сервер ресурсов (r2) на 8002.
шаг1:
Я зашел в админ-панель oauth-сервера, создал пользователя u1 для ресурса r1 и пользователя u2 для ресурса r2.Я зашел в модуль приложений в админ-панели, зарегистрировал r1 и r2 в приложениях с паролем владельца ресурса типа предоставления.Чтобы сгенерировать токен доступа, я позвонил в конечную точку токена
POST -d "grant_type=password&username=u1&password=u1password" -u "clientid of R1:clientsecre of fR1" http://localhost:8000/o/token/
Я получил токен доступа
{"access_token": "KdAOMZBiMomVxpvjAWErwVGog6NRRH", "expires_in": 86400, "token_type": "Bearer", "scope": "read write introspection", "refresh_token": "ffgkZZ5NtVFh4REs0TbFAALNkJqXVQ"}
шаг 2:
Скажите, что выше сгенерированный мной токен доступадля сервера ресурсов R1, поэтому я пошел к файлу настроек R1 и добавил этот токен для самоанализа
OAUTH2_PROVIDER = {
'RESOURCE_SERVER_INTROSPECTION_URL': 'http://localhost:8000/o/introspect/',
'RESOURCE_SERVER_AUTH_TOKEN': '9b2uVud7WXHEdyolznvvkM3KwWfkVe', # OR this but not both:
#'RESOURCE_SERVER_INTROSPECTION_CREDENTIALS': ('5sRVXLoTQj9vlkLWaziIMZrgra1keupWIQ2On2hX','5jwMxls1JiAiQiNVnRTtbjmzgRO20FEHD0BBdiSAwvSL1XswZKqglDRke2L8Ig77ol7OE3ZdsA9SE7sry0u3BXwd1OvfFfhDVJFSLWlPG6g1vB3w4ZFc1g8ZwgzXJooc'),
}
шаг 3: я проделал тот же процесс и для сервера ресурсов R2.
Вопрос 2: Правильно ли этот процесс регистрации сервера с несколькими ресурсами?Правильно ли я настроил интроспекцию?
Вопрос 3: Как мне зарегистрировать разные микроуслуги, работающие на одном и том же сервере ресурсов?
Шаг 4: Предполагая, что теперь у меня есть сервер аутентификации, готовый кгенерировать токен для ресурсов r1 и r2.
Теперь, чтобы смоделировать сценарий, в котором разработчик, который хочет интегрировать мой API с его приложением, хочет сгенерировать токен доступа, должен сначала зарегистрировать свое приложение на сервере аутентификации, я зарегистрировал приложение (приложение разработчика) всервер авторизации с учетными данными клиента типа «Грант».
Вот так теперь выглядит моя панель администратора с R1 с пользователем U1 и R2 с U2, зарегистрированным как сервер ресурсов и приложение для разработчиков, не связанное с каким-либо пользователем, являющимся клиентом, который хочет получить доступ к любомуиз этих ресурсов.
шаг 5: Имитируя, как разработчик сгенерировал бы токен доступа, я сгенерировал токен доступа, подобный этому 
Примечание. Я использовал идентификатор клиента и секрет клиента Resource R1 и сгенерировал токен доступа, но я могу успешно использовать один и тот же токен доступа даже для Resource R2 и его работы.
Вопрос 3: Почему маркер доступа, сгенерированный мной с использованием идентификатора клиента R1 и секрета клиента, работает даже для R2.Я что-то здесь не так делаю?По сути, я хочу иметь возможность создавать токены доступа для разработчика специально для ресурса.Я знаю, что есть область действия и разрешения, но могу ли я сгенерировать токен доступа только для определенного ресурса?Что мне нужно сделать, чтобы добиться этого, мне нужно расширить или добавить некоторую логику?
Вопрос 4: Правильно ли я думаю об использовании типа предоставления клиентских учетных данных и какие шаги я выполнил для регистрации ресурсов сервера?и клиентское приложение, которое будет использовать сервер ресурсов правильно?
Спасибо за любую помощь