Реализация аутентификации OAuth 2.0 с помощью API Laravel

в настоящее время я создаю веб-приложение, которое является интерфейсом AngularJS, который взаимодействует с RESTful API, построенным с помощью Laravel. Я делаю хороший прогресс, но мне трудно понять, как обрабатывать аутентификацию пользователя.

мне посоветовали, что я должен использовать OAuth для аутентификации, и я решил использовать его, поскольку это может быть опыт обучения для меня. Пакет, который я использую, чтобы справиться с этим что OAuth2-серверу-что Laravel.

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

в Библиотека OAuth2 имеет тип гранта "поток паролей", который, кажется, мне нужен, однако он также принимает client_id и client_secret параметры, которые я не хочу. Запрос URI выглядит примерно так:

POST https://www.example.com/oauth/access_token?
grant_type=password&
client_id=the_client_id&
client_secret=the_client_secret&
username=the_username&
password=the_password&
scope=scope1,scope2&
state=123456789

но чего я хочу, так это просто:

POST https://www.example.com/oauth/access_token?
grant_type=password&
username=the_username&
password=the_password

как я должен предоставить идентификатор клиента и секрет пользователя, который еще не прошел аутентификацию?

есть ли другой грант, который я могу использовать, или то, что я хочу достичь, просто не подходит для OAuth?

7
angularjs authentication laravel oauth php

3 ответов

примите во внимание, что client id и client secret не являются параметрами, которые вы должны принудительно передать конечному пользователю. Они статичны и определены в/для вашего клиентского приложения (angular app в этом случае).

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

и это все на самом деле.

кроме того, вы можете рассмотреть возможность использования неявного Поток грантов в случае создания приложения только для js, поскольку хранение секретного клиента и токена обновления в приложении JS небезопасно. Использование неявного гранта в конечном продукте может выглядеть как окно входа в soundcloud и более безопасно, поскольку токен получен на стороне сервера без раскрытия тайны клиента.

другой способ, если вы все еще хотите использовать поток паролей, - это создание прокси для обновления токенов. Прокси-сервер может скрыть маркер обновления в зашифрованном файле cookie только http, а js-приложение-нет попросите свой api для нового токена, но прокси вместо этого. Прокси считывает токен обновления из зашифрованного файла cookie, запрашивает у api новый токен и возвращает его. Таким образом, маркер обновления никогда не отображается. Если вы установите токен ttl в течение часа, скажем, то кража токена будет довольно " бессмысленной* "в случае обычного приложения, а кража токена обновления будет"невозможной*".

*конечно, если кто-то действительно хочет, он, вероятно, может взломать его любым способом.

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

9

вам чего-то не хватает в спецификации OAuth. The client_id и client_secret действительно важны при запросе маркера доступа при использовании метода пароля OAuth v2. Фактически, они важны для каждого метода, который дает вам маркер доступа. Они идентифицируют приложение или сервер, который выполняет запрос.

например, предположим, у вас есть API, 2 мобильных приложения и другой сервер, который выполняет некоторые задачи с вашим API. Вы создадите 3 клиенты со своими client_id и client_secret. Если ваше приложение имеет различные уровни доступа (они называются scopes в OAuth v2), то client_id соответствующий другому серверу сможет вызывать функции вашего API, которые требуют области admin в то время как ваше мобильное приложение сможет вызывать только функции вашего API, которые требуют basic область, если вы определили области, как это.

если ваш API вырастет в будущем, это действительно важно. Другой пример, давайте представим, что вы дали ключ API (пара client_id и client_secret) одному из ваших друзей, и он построил хорошее мобильное приложение с вашим API. Если однажды он начнет делать непослушные вещи с вашим API, вы не сможете остановить его очень легко. В то время как вы могли бы просто удалить его пару ключей, если бы вы следовали принципам OAuth v2.

OAuth v2 нелегко понять, найдите время, чтобы прочитать спецификации и хорошие учебники, прежде чем разрабатывать ПРИКЛАДНОЙ ПРОГРАММНЫЙ ИНТЕРФЕЙС.

полезные ссылки :

0

просто чтобы добавить немного к отличному ответу plunntic: помните, что " клиент "не связан с" пользователем", поэтому, когда я использую поток паролей, я просто определяю client_id и client_secret как константы в приложении AngularJS, чтобы сообщить бэкэнду api: Эй, это приложение браузера, которое используется для запроса токена.

-1