Какой тип предоставления использовать для аутентификации стороннего клиента для доступа к API?

Я впервые создаю сторонние API. У меня есть приложение laravel, использующее паспорт для аутентификации. Я создаю несколько API, чтобы предоставлять свой контент другим партнерам. Я изучал, какой тип гранта использовать для этого типа сценария.

Сначала мне на ум приходит предоставление учетных данных клиента. Но нет пользователя, связанного с этим типом гранта, что будет затруднительно для отслеживания доступа к API (для создания отчета о доступе к клиентскому API), и в этом случае токен обновления не предоставляется.

Второй - тип предоставления пароля. У этого метода есть пользователь, а также предоставляется токен обновления. Но я не уверен, что это правильный путь.

Может ли кто-нибудь предложить, какой тип гранта использовать для этого типа сценария? Любая помощь будет оценена по достоинству. Спасибо


person amansoni211    schedule 17.12.2018    source источник
comment
Почему вы думаете о типах грантов, если вы просто потребитель токена? Если вы создаете API, вы должны получить токен доступа, проверить его (действительность, области действия) и выполнить операцию или отклонить ее.   -  person Ján Halaša    schedule 17.12.2018
comment
Если вы ищете способ связать конечного пользователя с клиентом, искали ли вы возможность использования OpenID Connect? Вероятно, он будет использовать authorization_code или неявный поток, в зависимости от того, как выглядит ваша архитектура.   -  person rj2700    schedule 17.12.2018
comment
@ rj2700 Мне не нужно подключать конечного пользователя к клиенту. это только я и клиент. Я отдаю свой отобранный контент клиенту.   -  person amansoni211    schedule 18.12.2018
comment
@ JánHalaša Верно, я думаю, мне стоит отказаться от идеи использования паспорта laravel.   -  person amansoni211    schedule 18.12.2018


Ответы (1)


В вашем случае вы можете использовать метод токена персонального доступа. Токен личного доступа - это токен с долгим сроком службы, который нельзя отозвать или обновить токен, но вы можете настроить срок его действия.

person Wellwisher    schedule 27.12.2018
comment
Это тоже хороший вариант. Но я перешел на простой JWT-Auth, потому что я думаю, что OAuth2 в этом случае не нужен. - person amansoni211; 28.12.2018
comment
Я не уверен в JWT-Auth, но личный токен доступа подготовлен для сервисных решений. - person Wellwisher; 28.12.2018