Spring boot REST api security для Android-приложения с помощью входа в Google + Facebook

Я создаю приложение с 2 слоями: -

1. Родное Приложение Для Android - содержит возможность входа через Facebook + Google, чтобы сделать вход менее болезненным.

2. Сервер Java с использованием Spring Boot - типичные конечные точки MVC, такие как экраны администрирования REST api + UI.

Facebook (FacebookSdk) и Google (GoogleApiClient) signin части работают и протестированы с использованием следующих зависимостей Android: -

dependencies {
   compile 'com.facebook.android:facebook-android-sdk:4.6.0'
   compile 'com.google.android.gms:play-services-auth:9.0.0'
   ....

}

API-интерфейс мудрые мы имеем: -

/api/signin - вызывается, когда пользователь успешно входит в систему с помощью Facebook + Google и создает запись в users таблицы базы данных.

существует также ряд других конечных точек API, например, предложения

/api/offers/<user_id> - возвращает предложения уже зарегистрированному пользователю.

Я не уверен в лучшей практике, в которой: -

  1. как приложение android делает API-вызовы / api / signin конечные точки REST (т. е. какие заголовки и т. д. Можно отправить в то, что я бы предположил, является конечной точкой без залога потому что незарегистрированные пользователи будут поражать этом). Кроме того, какие поля можно сохранить в users таблица db?

  2. как приложение android делает API-вызовы, например / api / предложения/ для уже зарегистрированных пользователей? т. е. когда токены etc должны Приложение для Android передать?

  3. лучший способ для spring security защитить эти конечные точки.

предполагая, что OAuth 2-это путь, но любые советы / указатели будут наиболее оценены.

8
android android-facebook android-security spring-boot spring-security

1 ответов

Ans:1 / api / signin во время входа в приложение будет отправлять информацию о пользователе на сервер, и сервер будет генерировать токен, и этот токен вернется в signin приложение может быть сохранить этот токен, это может быть время от времени. вы можете использовать любую http-библиотеку для веб-службы,такой как volley, Retrofit и т. д.

поля, которые необходимо хранить в БД: userId, userName, userToken.

Ans: 2 / api / offers/ вы можете проверить идентификатор пользователя в БД, если он существует там вы бросите msg, уже присутствующий в ответе веб-службы.

Ans: 3 используйте реализацию SSL для вашей веб-службы, которая была бы очень безопасной, и, как вы упомянули, вы собираетесь использовать токен для каждого пользователя, чтобы он был доступен только для аутентификации пользователя.

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

2