Asp.Net Core 2.2 - Понимание промежуточного программного обеспечения аутентификации и внешних логинов - PullRequest
0 голосов
/ 24 января 2019

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

Я считаю, что моя цель довольно проста. У меня есть веб-приложение, которое поддерживает только входы внешних поставщиков (а именно: Facebook, Twitter и LinkedIn). Я не хочу поддерживать аутентификацию с помощью cookie, поскольку не будет поддержки пользовательских имени пользователя и пароля.

Моя первая проблема - определить схему аутентификации по умолчанию. Ниже мой startup.cs:

services.AddAuthentication()
        .AddFacebook(/* options */)
        .AddTwitter(/* options */)

Если я определяю действие контроллера с атрибутом Authorize, я не получаю ошибку, определенную схемой аутентификации по умолчанию, когда я прохожу этот маршрут. Однако я хочу, чтобы пользователи перенаправлялись на мой маршрут входа в систему, если они не авторизованы. Если я изменяю startup.cs, как показано ниже, все это работает, но тогда я думаю, что я поддерживаю cookie (аутентификацию старых форм?), Которую я не хочу.

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
        .AddCookie()
        .AddFacebook(/* options */)

Другая моя проблема в том, что я не знаю, что происходит под капотом вызова AddFacebook (). Если я настрою свое промежуточное программное обеспечение таким образом и войду в систему через Facebook, я волшебным образом получу все необходимые токены, утверждения и внезапно у меня будет установлен файл cookie приложения, и мой маршрут обратного вызова fb_login может получить доступ к токену Facebook! Когда я проверяю сетевые запросы, я вижу, что есть путь к входу в Facebook, который я не определил, и я предполагаю, что под капотом он вызывает HttpContext.SignInAsync () и т.д ..., но если я обновляю свой fb- войдите в систему обратного вызова и проверьте, если

HttpContext.AuthenticateAsync(FacebookDefaults.AuthenticationScheme) 

возвращает Success = true нет! возвращает false! Но это было правдой всего секунду назад?

Кроме того, когда мне следует использовать такие методы, как AuthenticateAsync () и SignInAsync ()?

Короче говоря, мне нужно учебное пособие или документация, объясняющая это промежуточное ПО без asp.net Identity Framework, EntityFramework и шаблоны.

Я хочу понять, как простой вызов AddFacebook () связывает все, и если я хочу сделать это вручную (скажем, с помощью AddOauth), как я могу достичь той же функциональности?

Я не фанат "автоматически работающего" кода, поэтому, если кто-то сможет объяснить, что здесь происходит, я буду очень признателен.

1 Ответ

0 голосов
/ 24 января 2019

Проверка подлинности cookie используется для сохранения аутентифицированного состояния между запросами. Этому нет замены, и нет, это не то же самое, что аутентификация форм, хотя в обоих случаях используются файлы cookie. Причина этого заключается в том, что именно cookie-файлы заставляют государство работать по протоколу HTTP, который сам по себе не имеет состояния. Если исключить использование куки, то нет другого механизма для поддержания состояния.

Использование чего-то вроде схемы авторизации Facebook напрямую авторизует первоначальный запрос, но опять же, поскольку состояние отсутствует, следующий запрос больше не аутентифицируется без повторного прохождения потока OAuth Facebook.

Короче говоря, другие схемы аутентификации существуют для таких вещей, как API, где каждый запрос обычно аутентифицируется индивидуально через что-то вроде заголовка Authorization. Веб-браузер не работает таким образом, и вместо этого полагается на куки, обрабатывают последующую авторизацию. Нет куки, нет аутентификации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...