Межплатформенная аутентификация с использованием ASP.NET Web API

Question

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

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

Вопросы:

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

Answer 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, который клиент должен передать обратно для аутентифицированных запросов.

Так что давайте пройдемся по нему

1. Клиент запрашивает защищенные данные
2. Клиент не авторизован, возвращает ответ с несанкционированным кодом состояния
3. Клиент отправляет учетные данные для аутентификации, которые должны быть защищены через HTTPS
4. После проверки клиент получает токен через заголовок HTTP или любой другой способ, который вам подходит
5. Клиент пытается снова запросить защищенные данные, на этот раз прикрепил токен к запросу
6. Атрибут AuthorizeTokenAttribute провериттокен и разрешить выполнение действия.

Также проверьте этот пост Джона Петерсена. Обеспечение безопасности вашего ASP.NET Web API

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

var config = GlobalConfiguration.Configuration; config.Filters.Add (new CustomAuthAttribute ());

{ пространство имен Customss { Открытый класс 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


    }


}

} }