Тип oauth-гранта для Android-приложения с весенней загрузкой - PullRequest
0 голосов
/ 27 марта 2019

У меня есть андроидное приложение в качестве клиента и служба весенней загрузки в бэкэнде с конечными точками REST.Я хочу знать наилучшую возможную стратегию аутентификации с помощью oAuth2 (без подхода социального входа).

В настоящее время я использую Spring oauth Security и у меня запущен сервер авторизации (пользователь подписывается с помощью электронной почты и пароля).Я использую тип предоставления "пароль", чтобы получить токены доступа в приложении для Android.Однако этот подход требует, чтобы приложение Android отправляло идентификатор клиента и секрет в запросе.Я прочитал несколько сообщений , которые предполагают, что этот тип гранта не идеален.Я не возражаю против получения пароля пользователя, но я думаю, что хранение клиентского секрета в приложении не очень хороший подход.

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

Я нашел сообщение , где люди предлагают использовать поток кода авторизации с PKCE.Но это, очевидно, еще не работает с spring .

Итак, теперь мне интересно, как другие родные мобильные приложения обрабатывают аутентификацию?Они не используют токен доступа?Как лучше всего поддерживать аутентификацию при работе с мобильным приложением и весенним бэкэндом?

1 Ответ

0 голосов
/ 28 марта 2019

Spring Security OAuth поддерживает потоки password и authorization_code без секрета клиента , что означает «общедоступный клиент».Поскольку у вас есть Сервер авторизации и , нативное приложение и , вы можете использовать нативное приложение, принимающее учетные данные, поэтому разумно, чтобы ваше нативное приложение использовало общедоступный клиент с грантом password.введите.

Если вы решите, что ваше нативное приложение не должно принимать учетные данные, тогда PKCE является наилучшей практикой.Использование потока authorization_code с общедоступным клиентом является рекомендуемой альтернативой PKCE :

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

И это будет означать, как вы упомянули, выпрыгнув в браузер .

...