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

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

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

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

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

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

Я бы очень признателен за любые отзывы, которые есть у вас на этом сайте.

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

Ответы

Ответ 1

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

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

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

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

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

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