ASP.NET Web API/HMAC Аутентификация, как авторизовать от имени пользователя?

Question

Я читаю эту статью http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/, и я понимаю, как работает HMAC, я думаю.

Проблема в том, что HMAC, похоже, аутентифицирует стороннюю сторону (ретрансляционную сторону). Что, если третья сторона хочет передать пользователю мою систему и свой пароль для извлечения конкретных данных пользователя? Я не хочу использовать OAuth 1.0 или 2.0, потому что с ними связаны разные проблемы. Мне кажется, мне нужно также аутентифицировать пользователя, а не просто разрешать?

Например, мобильное приложение Evernote, оно запрашивает у меня имя пользователя/пароль, и я уверен, что он вызывает какой-то веб-API в фоновом режиме. Он не использует OAuth 2.0 правильно? Потому что я не вижу, чтобы я перенаправлялся на сайт провайдера, чтобы «разрешить». В этом случае, как мое имя пользователя/пароль было передано в сервисную службу?

[Редактировать]

Подумав немного, я предполагаю, что SSL является решением? После того, как у вас есть SSL, вы можете передать имя пользователя/пароль на мой веб-api в текстовом формате, а затем я делаю все, чтобы аутентифицировать стороннюю версию PLUS, аутентифицировать пользователя и отвечать данными пользователя?

В этом случае недостатком является то, что я должен доверять третьей стороне? Таким образом, они не сохраняют имя пользователя пользователя + пароль, это правильно?

Answer 1

Во-первых, только потому, что вы не видите перенаправления, это не значит, что OAuth не используется. Я не говорю, что Evernote использует OAuth. Я не знаю их архитектуры, но ресурс Credentials Credentials владельца ресурса, который является частью OAuth 2.0, подходит для сторонних приложений и не перенаправляет.

Во-вторых, если вы хотите, чтобы ваши пользователи не делились своими учетными данными с сторонним приложением, которое использует ваш веб-API, OAuth 2.0 - отличный вариант и не уверен, почему вы не хотите использовать OAuth. Вы также можете попробовать WS-Federation с помощью WIF, хотя это SOAP-ish. Последним вариантом будет ваш собственный механизм переадресации, с помощью которого ваши пользователи, отправляющие свои учетные данные на вашей веб-странице, будут обеспечены, но это очень рискованно и не рекомендуется. Зачем изобретать велосипед? Помимо этого, вы должны доверять только третьей стороне.