Используете OAuth для межсерверной аутентификации?

Question

В настоящее время я работаю над тем, чтобы указать новый партнерский / публичный API моей компании, который будет ориентированным на ресурсы веб-сервисом RESTful. Недостающим элементом головоломки на данный момент является аутентификация / авторизация.

Требования:

1. Первоначально он должен работать для межсерверной среды, например серверное приложение должно быть в состоянии идентифицировать себя, чтобы мы знали, кто вызывает API.
2. В будущем мы хотели бы разрешить ему олицетворять учетные записи пользователей, а также идентифицируемый сервер будет иметь токен, который представляет учетную запись пользователя в течение ограниченного периода времени.

OAuth представляется идеальным для (2) процесса получения токена, перенаправления на веб-сайт, где пользователь вводит свои учетные данные для его авторизации, а затем использования этого токена, который идентифицирует / аутентифицирует как приложение, так и пользователя.

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

Answer 1

На самом деле есть две спецификации OAuth: 3-сторонняя версия и 2-сторонняя версия. Трехногая версия - та, которая привлекает наибольшее внимание.

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

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

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

Получить одновременно 2-х и 3-х ногу одновременно довольно сложно - но это возможно (сейчас у Google это работает). http://code.google.com/apis/accounts/docs/OAuth.html

Answer 2

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

(Вы можете использовать любой тестовый клиент , чтобы помочь вам выполнить эту часть вручную, или пока вы сами внедряете сервер: используйте так называемый OAuth с двумя ножками.)

Answer 3

Greg:

Я работаю над расширением ядра OAuth, которое, я думаю, может вам ответить. Мы хотели писать приложения на основе нашего собственного API, но чувствовали, что не имеет смысла не позволять нашим собственным приложениям (как поставщику услуг) собирать учетные данные непосредственно из приложения пользователя / потребителя - поскольку мы уже будем считаться доверенными вечеринка для себя.

Расширение допускает 1-го, 2-го и, конечно же, 3-го участника (традиционный OAuth) при использовании безопасности токенов и секретов, а также подписи и т. Д., Которые обеспечивает Протокол.

Наша бета-документация по расширению может быть найдена здесь .

Answer 4

Если речь идет только об обмене данными между серверами, я бы подумал об использовании авторизации на основе ключа API - как в bit.ly или FriendFeed.