Атрибут [авторизация] веб-API без входа пользователя в систему или запроса токена с паролем?

Поправьте меня, если я чего-то не понимаю. Я работаю со свежим приложением веб-API, созданным из шаблона VS.

  • Пользователь регистрируется прямо на странице входа в приложение веб-API.
  • Похоже, что пользователь может зарегистрироваться извне приложения веб-API (с ЛЮБОГО устройства, которое знает URL-адрес api / Accounts), но для этого требуется передача конфиденциальной информации в виде обычного текста.
  • Образец ValuesController имеет [Authorize].
  • Доступ к / api / Values ​​из браузера приведет к выдаче 401, если пользователь не вошел в систему.
  • Доступ к / api / Values ​​из Fiddler также вызовет ошибку 401, даже если пользователь вошел в систему. Это связано с тем, что для этого требуется заголовок Authorize: Bearer, токен доступа которого недоступен извне веб-приложения.
  • Существует конечная точка токена, которую мы можем использовать для запроса токена извне приложения, но для использования встроенной конечной точки токена требуется, чтобы имя пользователя и пароль были отправлены в виде обычного текста.

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

Предположим, что мне удалось добиться создания приемлемого токена доступа от клиента. Будет ли атрибут [Authorize] по-прежнему блокировать доступ, потому что пользователь технически не вошел в систему? Или [Authorize] действительно регистрирует пользователя, если это не приводит к ошибке 401?


asp.net-mvc oauth asp.net-web-api owin katana
person Mickael Caruso    schedule 15.02.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

AuthorizeAttribute заблокирует доступ, если свойство IsAuthenticated текущего IIdentity имеет значение false. Он полностью отделен от токена доступа.

person user3137652    schedule 03.04.2014

arrow_upward
0
arrow_downward

Ваши шаги в порядке. Но я думаю, что вы смешиваете свое понимание последней части с аутентификацией файлов cookie и аутентификацией токена.

Будет ли атрибут [Authorize] по-прежнему блокировать доступ, потому что пользователь технически не вошел в систему? Или [Авторизовать] действительно регистрирует пользователя, если это не приводит к ошибке 401?

С аутентификацией файлов cookie это будет проблемой, поскольку технически пользователю потребуется войти в систему, а на сервере должен существовать действующий сеанс.

Однако это не относится к аутентификации по токену. Если у вас есть действующий токен на предъявителя, вы можете получить доступ к API с любого устройства.

person Nilav Baran Ghosh    schedule 19.12.2015