Я работаю над приложением для Android, где существует система аутентификации, основанная на электронной почте / пароле.
Всякий раз, когда пользователь успешно входит в систему с именем пользователя и паролем, токен JWT создается и возвращается в приложение для совершения аутентифицированных вызовов.
Теперь я хочу поддержать вход в Facebook, однако некоторые этапы связи с OAuth мне не совсем понятны.Я искал документацию, но она кажется немного расплывчатой.
Это процесс, который я себе представляю:
- Пользователь нажимает кнопку Facebook
- Приложениезапрашивает у сервера маркер состояния
821379812739871293 и вызывает URL-адрес FB, настроенный так: https://www.facebook.com/v3.2/dialog/oauth?client_id=123&redirect_uri=https://<myappdomain.some>/fb-callback&state=821379812739871293 - Приложение открывает веб-просмотр, где пользователь может принять логин и поделиться адресом электронной почты.
- Facebook перенаправляет на
redirect_uri что-то вроде этого https://<myappdomain.some>/fb-callback?code=h21i3i2h13&state=821379812739871293 Во время обратного вызова сервер:
- проверяет,
state tokenсуществует, в противном случае он отклоняет обратный вызов FB - , который он использует
https://graph.facebook.com/v3.2/oauth/access_token для получения access_token - , он использует API FB для получения адреса электронной почты (необходимо проверить, как это сделать, нодолжно быть достаточно для вызова
/me) - , если электронная почта существует (иногда ее нет), она пытается найти существующего пользователя в БД или добавляет нового
[UNCLEAR PART] Обратный вызов возвращает перенаправление на некоторый зарегистрированный в ОС URL-адрес like http://<myappdomain.some>/login-success?apiKey=<jwt-token>
[UNCLEAR PART] приложение считывает ключ API из URL-адреса и продолжает выполнять вызовы бэкэнда
Это правильная / обычная практика?
Спасибо!
РЕДАКТИРОВАТЬ: чтобы уточнить, я видел этот ответ , однако это плохая практикахранить секрет клиента на стороне приложения.Более того, в будущем я мог бы интегрировать аутентификации Instagram и LinkedIn, которые, кажется, не позволяют или не поощряют обход сервера с неявным oauth.