Кросс-платформенная аутентификация с использованием веб-API ASP.NET

Как я даже начинаю кодирование с помощью ASP.NET Web API, так что это кросс-платформенный интерфейс для поддержки настольных компьютеров, мобильных устройств и Интернета? Я читал о некоторых методах проверки подлинности RESTful, таких как использование токенов в заголовке.

Существуют ли какие-либо примеры проектов, которые используют этот метод?

Вопросы:

  • Если нет, как мне исправить атрибут [Authorize], чтобы прочитать токен?
  • Как мне создать этот токен? Я не думаю, что могу использовать formauthentication, потому что это использует файлы cookie.
  • Как мне обрабатывать фактическую авторизацию, клиент посылает сырой пароль и имя пользователя, затем я генерирую токен или есть какой-то другой способ?
  • Как мне обрабатывать, когда мой сайт использует его? Я слышал, что это обрабатывается иначе, чем когда приложение использует его, например, получить домен и разрешить его.

ОТВЕТЫ

Ответ 1

Я думаю, что токены были бы надежным способом. Аутентификация форм основана на файлах cookie для Интернета. Однако не самая идея для всех не-браузеров.

Я бы предложил создать настраиваемый атрибут AuthorizationFilterAttribute и переопределить метод OnAuthorization. В этом методе вы можете проверить наличие токена, который вы выдали клиенту после того, как они предоставили действительные учетные данные. Вы можете использовать этот атрибут для любого метода или контроллера, который вы хотите проверить. Здесь образец, на который вы можете ссылаться

 public class AuthorizeTokenAttribute : AuthorizationFilterAttribute 
{      
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext != null)
        {                
                if (!AuthorizeRequest(actionContext.ControllerContext.Request))
                {
                    actionContext.Response = new HttpResponseMessage(HttpStatusCode.Unauthorized) { RequestMessage = actionContext.ControllerContext.Request }; 
                }
                return;
        }
    }

    private bool AuthorizeRequest(System.Net.Http.HttpRequestMessage request)
    {
        bool authorized = false;
        if (request.Headers.Contains(Constants.TOKEN_HEADER))
        {               
            var tokenValue = request.Headers.GetValues("TOKEN_HEADER");
            if (tokenValue.Count() == 1) {
                var value = tokenValue.FirstOrDefault();               
               //Token validation logic here
               //set authorized variable accordingly
            }                
        }
        return authorized;
    } }

TOKEN_HEADER - это просто строка, представляющая HTTP-заголовок, который клиент должен передать обратно для аутентифицированных запросов.

Итак, пройдем через него

  • Клиент запрашивает защищенные данные
  • Клиент не авторизуется, возвращает ответ с кодом неавторизованного статуса
  • Клиент отправляет учетные данные для аутентификации, которые должны быть защищены через HTTPS
  • После проверки клиент получает токен через HTTP-заголовок или что-то для вас работает
  • Клиент снова пытается запросить защищенные данные, на этот раз привязанный токен к запросу
  • AuthorizeTokenAttribute проверит токен и позволит выполнить действие.

Кроме того, проверьте это сообщение от Джона Петерсена. Обеспечение безопасности веб-API ASP.NET

Ответ 2

Существует множество способов аутентификации пользователей для службы REST. Использование токенов возможно, но просто используя Базовая аутентификация еще проще и стандартно и поперечно, как вы можете.

Не путайте authorization с authentication. Атрибут [Авторизовать] касается авторизации, но только после аутентификации пользователя с использованием какого-либо другого механизма. Авторизация полностью бесполезна, прежде чем выполнять правильную проверку подлинности.

Лучший ресурс для проверки - Доминик Байер, который является экспертом по этому вопросу.

Ответ 3

Я использую очень простой подход:

  • определить профиль доступа с его уникальным идентификатором accessId и accessKey (например, значением GUID хэшированного MD5).
  • сохранить такой профиль доступа в базе данных
  • каждый запрос (GET/POST/etc.) должен предоставлять accessId, queryHash (MD5 хэш-значение представляет запрос) и подпись (MD5 хэш-значение queryHash + accessKey). Конечно, клиент должен держать accessKey в безопасном месте!!!
  • сервер получает запрос, проверит accessId и подпись, используя тот же алгоритм вычисления, чтобы отклонить или предоставить доступ (аутентифицировать)
  • дальнейшая авторизация может быть выполнена по типу запроса с использованием профиля доступа

служба с таким подходом с использованием нового веб-API ASP.NET MVC может обслуживать любой тип клиента: браузер /javascript и собственный (рабочий стол или мобильный) и т.д.

Ответ 4

U может использовать ActionFilterAttribute и переопределять метод OnActionExecuting. Позже зарегистрируйте этот фильтр в global.cs, чтобы применить этот фильтр для всех таких действий, как это в методе запуска приложения

var config = GlobalConfiguration.Configuration;           config.Filters.Add(новый CustomAuthAttribute());

{ Таможня пространства имен { Открытый класс CustomAuthAttribute: ActionFilterAttribute

{

    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        // To inforce HTTPS if desired , else comment out the code
        if (!String.Equals(actionContext.Request.RequestUri.Scheme, "https", StringComparison.OrdinalIgnoreCase))
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest)
            {
                Content = new StringContent("HTTPS Required")
            };
            return;
        }

       // get toekn from the header

        var userToken = actionContext.Request.Headers.GetValues("UserToken");
         // Customer Logic to check the validity of the token.
        // U can have some DB logic to check , custom STS behind or some loca cache used to compare the values


    }


}

} }