Двуногий OAuth - ищет информацию - PullRequest
25 голосов
/ 20 мая 2009

Я хочу внедрить в нашу инфраструктуру новый API на основе REST, и, похоже, OAuth - путь.

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

Позже мы хотели бы разрешить использование API браузером, что превратит нашу авторизацию в трехстороннюю.

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

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

Я надеюсь найти отправную точку для получения дополнительной информации, дайте мне знать!

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

Ответы [ 3 ]

48 голосов
/ 06 июня 2009

Да, OAuth, вероятно, для вас.

На самом деле существует две спецификации OAuth: 3-сторонняя версия и 2-сторонняя версия. Большая часть внимания привлекает трехногая версия, и , а не та, которую вы хотите использовать.

Хорошей новостью является то, что 2-сторонняя версия делает именно то, что вам нужно, она позволяет приложению предоставлять доступ к другому через общий секретный ключ (очень похоже на модель веб-службы Amazon, вы будете использовать HMAC-SHA1). метод подписи) или через систему открытого / секретного ключей (используйте метод подписи: RSA-SHA1). Плохая новость заключается в том, что она еще не так хорошо поддерживается, как 3-сторонняя версия, поэтому вам, возможно, придется выполнить немного больше работы, чем в противном случае сейчас.

По сути, двухсторонний OAuth просто указывает способ «подписать» (вычислить хэш) несколько полей, которые включают текущую дату, случайное число, называемое «nonce», и параметры вашего запроса. Это очень затрудняет олицетворение запросов к вашему веб-сервису.

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

Это сложнее, чем вы хотели бы поначалу задуматься, но хорошая новость заключается в том, что многие люди потратили на это много времени, поэтому вы знаете, что ничего не забыли. Отличным примером является то, что совсем недавно Twitter обнаружил пробел в безопасности OAuth, над которым в настоящее время работает сообщество. Если вы изобрели свою собственную систему, вам придется самому разбираться со всем этим.

Удачи!

5 голосов
/ 20 мая 2009

Не забывайте различать аутентификацию и авторизацию. В некоторых местах, я считаю, что ОП смешивает два.

Например, когда сервер аутентифицирует кого-то, он обычно явно или неявно (с использованием файлов cookie) предоставляет маркер аутентификации, чтобы последующие запросы уже были авторизованы.

Это зависит от сервера, как долго хранятся учетные данные. Разумно планировать , что учетные данные в какой-то момент прекратятся. Просто подготовьте клиентский сервер к повторной аутентификации при получении ответа об ошибке «истек срок авторизации».

Вы не хотите пытаться предоставить сеанс с неограниченным сроком действия, поскольку:

  1. Все истекает в какой-то момент. Например, как клиентский сервер сможет снова получить доступ к приложению, если оно теряет питание или перезагружается?

  2. Вы создаете негибкую систему. Они имеют тенденцию ломаться чаще.

  3. Поскольку вы знаете, что хотите добавить дополнительные типы имен входа в будущем, вместо двух типов имен входа (серверные клиенты и клиенты браузера), сделайте только один тип входа в систему сейчас. Дополнительная работа для клиентского сервера будет заключаться в реализации возможности «повторного входа в систему по мере необходимости».
2 голосов
/ 11 июня 2009

OAuth окажется слишком сложным для наших нужд. Я решил принять схему аутентификации Amazon S3 просто потому, что она лучше подходит для нашей модели.

Спасибо за помощь в поиске ответа, хотя ..

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...