Как использовать OAuth с авторизацией форм

Мы действительно делаем это в нашем проекте. Решение было действительно простым. Вот основные моменты

• Имейте в виду, что спецификация OAuth не рекомендует хранить токен носителя oauth на клиенте.
• Убедитесь, что сервер приложений отправляет запросы аутентификации провайдеру oauth. Не делайте этого из клиента (кроме этапа авторизации, потому что у вас действительно нет выбора).
• Используйте фреймворк. Позвольте провайдеру членства обрабатывать билеты проверки подлинности.
• Создайте своего настраиваемого поставщика членства и попросите его управлять процессом аутентификации со сторонним поставщиком.
• После успешной аутентификации сохраните токены в сеансе или в заявке с идентификатором пользователя. Другими словами, сохраните токены доступа и обновления на сервере.
• Разрешить фреймворку сгенерировать билет аутентификации, как обычно
• Между билетом аутентификации и файлом cookie сеанса вы можете получить токен доступа из сеанса / заявки для выполнения запросов ресурсов.
• При связывании стороннего входа в систему вам, очевидно, придется позвонить провайдеру с токеном доступа, чтобы получить некоторую информацию, такую ​​как идентификатор пользователя facebook. Используйте это, чтобы связать вашего внутреннего пользователя с пользователем facebook.

Другие вещи, которые следует учитывать:

• Убедитесь, что вы завершили сеанс при выходе. Некоторые фреймворки будут очищать значения файлов cookie, но повторно использовать идентификатор сеанса. Убедитесь, что идентификатор сеанса не используется повторно.
• Используйте токен защиты от подделки с любым запросом, который требует информации о сеансе, которая должна быть практически всем. Это поможет вам убедиться, что файл cookie сеанса не был взломан.

Я думаю, это важный момент: как правило, с такими поставщиками, как facebook и twitter, вы используете поток авторизации, что означает, что вы должны использовать их форму для входа в систему. Они справляются с этим, а не вы. Существует «опция» имени пользователя / пароля (grant_type: password) с OAuth 2.0, но я не знаю, разрешают ли эти поставщики, потому что этот поток не требует, чтобы приложение идентифицировало себя.

Я думаю, вы в значительной степени поняли. Процесс предоставления авторизации будет выглядеть примерно так:

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

Если вы используете его только для аутентификации, вы не будете делать запрос с этим конкретным токеном доступа к их серверу ресурсов. Мне нужно больше узнать о вашей архитектуре, чтобы сказать больше. Однако, как правило, если у вас есть внутренний поставщик удостоверений, который обрабатывает роли и удостоверение, вы можете рассмотреть возможность использования федеративного поставщика удостоверений, который может преобразовывать сторонние токены во внутренний формат и хранить их вместе со сторонним токеном. Таким образом, вы все еще можете делать запросы к третьей стороне, если это необходимо, и у вас все еще есть то, что вам нужно для внутреннего перемещения, если это имеет смысл. Если это вообще беспокоит, дайте мне знать, и я объясню и эту ногу.

Forms auth обычно помещает файл cookie аутентифицированному пользователю, поэтому вы можете сделать то же самое и отправить тот же файл cookie, который отправляла форма auth.

Итак, при успешном обратном вызове OAuth от поставщика вы можете просто сделать что-то вроде этого:

  // here, we are called on a successful OAuth auth, so 
  // let's do Forms login by ourselves
  HttpCookie authCookie = GetFormsAuthCookie(email, true, true);
  context.Response.Cookies.Add(authCookie);

С помощью метода GetFormsAuthCookie, определенного следующим образом:

  private static HttpCookie GetAuthCookie(string userName, bool createPersistentCookie, bool httpOnly)
  {
      FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(2, userName, DateTime.Now, DateTime.Now.Add(FormsAuthentication.Timeout), createPersistentCookie, "SocialEmailLogin", FormsAuthentication.FormsCookiePath);
      string encryptedTicket = FormsAuthentication.Encrypt(ticket);
      if (encryptedTicket == null)
          throw new Exception("Obviously, something went wrong here. That shouldn't happen.");

      HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
      cookie.HttpOnly = httpOnly;
      cookie.Path = FormsAuthentication.FormsCookiePath;

      if (FormsAuthentication.RequireSSL)
      {
          cookie.Secure = true;
      }

      if (FormsAuthentication.CookieDomain != null)
      {
          cookie.Domain = FormsAuthentication.CookieDomain;
      }

      if (ticket.IsPersistent)
      {
          cookie.Expires = ticket.Expiration;
      }
      return cookie;
  }