Служебная аутентификация - аутентификация с использованием уже выданного токена доступа
Эти вопросы связаны с потоком аутентификации ServiceStack OAuth. Отладка FacebookAuthProvider Я вижу, что если параметр кода не является нулевым (полученный из перенаправления на URL-адрес диалога Facebook), он использует его для получения токена доступа. AuthProvider делает то же самое с OAuthAuthorizer.
Как насчет использования Javascript SDK для получения токена доступа (с модальным во всплывающем окне, без перенаправления) для одностраничных приложений. Есть ли конечная точка для аутентификации пользователя с выданным токеном доступа?
Кроме того, вы считаете это недостатком безопасности? Я считаю, что если пользователь сначала подписывает с провайдером учетных данных, а затем с провайдером OAuth, ServiceStack создает две отдельные учетные записи. Если сервер проверяет токен доступа с помощью API Facebook и возвращает действительный ответ, я думаю, что можно подписать уже существующего пользователя в приложении (я полагаю, что достаточно доверять поиску AuthUserDetails с поставщиком, равным Facebook).
1 ответ
FacebookAuthProvider следует тому же потоку провайдера OAuth, что и любой другой провайдер OAuth, который перенаправляет на удаленный сайт OAuth для захвата авторизации пользователей перед перенаправлением обратно с кодом, который Auth Provider использует для получения access_token для пользователя. Ни один из встроенных AuthProviders не имеет никакой зависимости от JavaScript SDK.
ServiceStack не создает 2 отдельных учетных записи пользователя, он создает 1 учетную запись пользователя, которая связана с каждым Auth Provider, с которым они прошли проверку подлинности во время проверки подлинности. Затем пользователь может пройти аутентификацию, используя любого из провайдеров аутентификации, с которыми он ранее проходил аутентификацию, для входа в свою учетную запись.
Только если пользователь еще не прошел проверку подлинности, когда он прошел проверку подлинности с помощью Facebook, он может создать отдельную учетную запись пользователя. Но он будет создавать новую учетную запись только в том случае, если не существует существующего User Account, зарегистрированного с тем же адресом электронной почты, в противном случае произойдет сбой с EmailAlreadyExists ошибка. Если были созданы отдельные учетные записи пользователей, они рассматриваются как две отдельные учетные записи, которые не связаны (т. Е. Имеют разные User AuthId), и в этом случае аутентификация с использованием любого поставщика аутентификации будет входить в две разные учетные записи пользователей.