Каков наилучший/рекомендуемый способ аутентификации пользователей, использующих отдых в Symfony?

Question

Я разрабатываю приложение rest apis в приложении symfony.

Прямо сейчас мой apis используется моим приложением только по интерфейсу (запросы ajax от Angularjs). В будущем я также хотел бы представить те же API-интерфейсы для сторонних приложений.

Также в будущем у меня будут Android, приложения для IPhone и т. Д.

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

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

Я хочу знать, как использовать этот комплект для аутентификации пользователей на моем веб-сайте через apis отдыха из моего приложения frontend?

В настоящее время я использую FOSUserBundle и form_long для аутентификации пользователя, но я изменяю интерфейс, чтобы использовать Angularjs и rest based. Таким образом, в идеале аутентификация должна просто работать как проверка подлинности form_login, но она должна основываться на отдыхе.

Я проводил исследования на него, и люди предлагают использовать «владелец ресурса Пароль учетные данные» Но для этого нужно секрет клиента выставляться в JavaScript, который не может быть безопасным

Он должен работать, например, пользователь вводит учетные данные пользователя и пароля, как это работает в случае form_login, но вместо перенаправления он должен просто вернуть access_token.

Должен ли я написать свой провайдер аутентификации custome, который использует UsernamePasswordToken и прослушиватель брандмауэра, например OAuthListener, который возвращает access_token? Будет ли это безопасно использовать?

Answer 1

вопрос с похож непродолжительным обсуждением здесь: Symfony2 FOSOAuthServerBundle grant type password requires client secret

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

Вы можете установить допустимые типы разрешений для каждого клиента OAuth, поэтому, если вы создадите мобильные приложения, вы захотите создать отдельную пару client_id client_secret для приложения и для интерфейсного модуля с единственно допустимым введите тип «пароль» для внешнего приложения.