Параметр state должен быть непрозрачным значением, которое нельзя угадать злоумышленником, поскольку оно не защищено от изменений. Если вам нужно отслеживать состояние, вы должны ссылаться на него, используя параметр state, но этот параметр должен быть рандомизирован и/или зашифрован. Хранение идентификатора поставщика в открытом тексте в параметре state небезопасно. Пользователи могут сами изменить параметр state, или злоумышленники могут создать запрос авторизации с выбранным им значением state.
Способ отслеживания провайдера заключается в сохранении его в состоянии бэкэнд-сессии и создании ссылки на этот сеанс/состояние, которое вы передаете в параметре state. Чтобы предотвратить подделку запросов на межсайтовый запрос, вы также должны сохранить зашифрованный/рандомизированный файл cookie, который связывает это состояние с браузером. Это описано более подробно: https://tools.ietf.org/html/rfc6749#section-10.12
Добавление:
Одна из проблем, с использованием OAuth 2.0 + поставщика конкретных расширений для входа в систему именно: вы не можете установить личность поставщика и пользователя таким образом, что работает для всех поставщиков в едином и общем виде. В вашем случае вам уже нужно знать поставщика, прежде чем вы сможете провести с ним разумное взаимодействие. Введите OpenID Connect: это профиль расширения OAuth 2.0, который стандартизован для семантики входа. Это даст вам проверяемый объект JSON (JWT) со стандартными значениями, которые сообщают вам, кто является провайдером (iss) и кто является пользователем (sub).
Объявление Google уже перенесено на OpenID Connect, так же как Microsoft и другие подобные Salesforce, надеюсь, что Facebook последует за ним.
Я бы использовал несколько разные URL-адреса. Даже параметр строки запроса. – ceejayoz
Итак, мой redirectURL может содержать параметр строки запроса? –
Конечно, почему бы и нет? – ceejayoz