ASP.NET Web Api (REST): аутентификация с использованием учетных данных пользователя или токена? Оставить регистрацию нового пароля ресурса пользователя свободным?

Я пытаюсь создать службу REST, используя asp.net web api, и все работает нормально, но теперь я столкнулся с тем, что делать с аутентификацией.

Я немного не понимаю, с чего начать, вот о чем я подумал.

У меня есть REST api, состоящий из нескольких ресурсов, для каждого ресурса потребуется регистрация пользователя, так что лучше всего сделать для этого? Должен ли я просто отправлять имя пользователя и пароль в заголовке при каждом вызове службы, чтобы я мог аутентифицироваться на сервере, используя

AuthorizationFilterAttribute

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

У меня также есть ресурс, который используется для регистрации нового пользователя, на самом деле единственное, что будет вызывать его, - это мои клиенты (Android, iPhone). ТАК, я должен оставить его БЕСПЛАТНЫМ от каких-либо методов аутентификации или поставить жестко закодированный пароль или что-то подобное, чтобы, по крайней мере, никто другой не мог регистрировать новых пользователей? Принимая во внимание, что услуга будет общедоступной в Интернете.

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


person Martin    schedule 07.07.2012    source источник


Ответы (1)


Следующая ссылка, кажется, охватывает некоторые разумные варианты самостоятельной работы http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/. Раздел «Токены на основе открытых / закрытых ключей» описывает подход, который я эффективно использовал в прошлом и, возможно, будет вам полезен.

В настоящий момент я использую http://identityserver.codeplex.com/ Thinktecture IdentityServer с носителем OAuth. tokens (тип предоставления «Учетные данные пароля владельца ресурса») ... Я считаю, что это очень хороший набор кода и примеров для работы, и клиенты IOS получают токены и вызывают WebApi.

Если вам действительно необходимо защитить экран регистрации, вы могли бы использовать сертификаты клиентов, установленные на устройствах, для аутентификации ... опять же, здесь может помочь служба Thinktecture https://identity.thinktecture.com/idsrv/docs/default.htm?RequestingatokenusingOAuth2.html. Хотя, если процесс регистрации безопасен, Что являются лучшими практиками для ссылок активации / регистрации / сброса пароля в электронных письмах с одноразовым идентификатором, например подтверждения и активации по электронной почте и т. д., может быть безопасно оставить общедоступным - все зависит от требований вашего бизнеса и желаемого рабочего процесса регистрации.

Вы должны, по крайней мере, использовать SSL на транспортном уровне, но, как вы предлагаете, безопасность на уровне сообщений, например. шифрование любых токенов очень желательно - в спецификации OAuth есть что сказать по этому поводу http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#mitigation.

Что касается истекающих токенов - мы, как правило, истекаем с той же периодичностью, что и наша политика изменения пароля; хотя сокращение срока действия важно (чтобы свести к минимуму влияние кражи токенов) и соображение, которое необходимо уравновесить с вашими требованиями. OAuth имеет концепцию токенов обновления Почему у OAuth v2 есть И токены доступа, и токены обновления? некоторые дискуссии и ссылки по этой теме здесь, в настоящее время мы не используем этот подход, так как сервер идентификаторов, который мы используем, в настоящее время не поддерживает его.

Также важно обеспечить безопасность ваших токенов, например мы используем KeyChain в IOS, но также думаем о политиках управления мобильными устройствами, если это возможно, как если бы эти токены или пароли были одним из устройств, которое они могут быть украдены, возможно, рассмотрим обнаружение взлома, принудительное использование экрана блокировки и т. д.

person Mark Jones    schedule 09.07.2012
comment
Спасибо, Марк, я посмотрю, мне было на что посмотреть ... Спасибо за помощь - person Martin; 11.07.2012