Facebook OAuth не получает профиль пользователя в ASP. NET Core 2.2

Question

Я снова борюсь с идентичными частями ASP. NET Core 2.2. На этот раз его логин на Facebook. Google и Microsoft работают с некоторыми небольшими изменениями, но Facebook поставил меня в тупик.

Вот мой конфиг.

        "Facebook": {
            "ClientId": "See secrets.json",
            "ClientSecret": "See secrets.json",
            "AuthorizationEndpoint": "https://www.facebook.com/v5.0/dialog/oauth",
            "TokenEndpoint": "https://graph.facebook.com/oauth/access_token",
            "UserInformationEndpoint": "https://graph.facebook.com/me?fields=id,name,first_name,email",
            "CallbackPath": "/oauth2/facebook",
            "Scope": [ "public_profile", "email" ]
        }

Используя Fiddler, я не вижу попыток вызвать ресурс /me, чтобы получить профиль. Я могу увидеть, как обратный канал вызывает токен доступа, и я вижу, что ответ мне кажется JSON хорошим, и токен работает; Я могу вызвать API Graph Facebook вручную и получить свой профиль.

Я заставил Fiddler отследить работающий логин Google, и я вижу, что токен возвращается с той же схемой JSON, которую использует Facebook, и затем другой четкий запрос / ответ на обратном канале для получения моего профиля Google.

Facebook возвращает { "access_token", "token_type", "expires_in" }, а Google возвращает { "access_token", "expires_in", "scope", "token_type", "id_token" }.

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

У меня нет идей.

---

Точно такая же проблема после настройки LinkedIn. Токен возвращается в отличном состоянии, но даже не пытается позвонить, чтобы получить профиль.

Каким дорогостоящим кошмаром является структура Identity.

Answer 1

У меня работает логин на Facebook. Я смотрел на то, почему работают Microsoft и Google, и увидел, что они используют свои собственные методы расширения, такие как AddGoogle, а не vanilla AddOAuth.

Просмотр кода на GitHub показывает, что каждый из именованные используют пользовательский обработчик.

Это говорит мне о том, что каждый поставщик OAuth неспособен следовать стандарту, поэтому для каждого из них необходим специальный код! Прекрасная работа всем. Высшие оценки.

Я попробую использовать обработчики Google (et c) для LinkedIn и посмотрю, являются ли какие-либо "совместимыми".