Используя OAuth для сервера к аутентификации сервера?
проверьте ваш ключ API или свяжитесь с ними и спросите о разрешениях
Когда я попытался использовать образец curl с использованием вашего ключа, он также завершился неудачно с 403
$ curl -G https://octopart.com/api/v3/parts/match -d queries="[{\"mpn\":\"SN74S74N\"}]" \
-d apikey=eb49732b \
-d pretty_print=true
{
"__class__": "ClientErrorResponse",
"message": "Forbidden request"
}
Однако с EXAMPLE_KEY запрос выше преуспевает
4 ответа
Да, время жизни токена можно настроить так, чтобы оно не истекло, пока вы не скажете это. Таким образом, вы (вручную) завершите аутентификацию и авторизацию и сохраните авторизованный токен для дальнейшего использования.
(Вы можете использовать любой тестовый клиент , чтобы помочь вам выполнить эту ручную часть, или пока вы внедряете сервер самостоятельно: используйте так называемый двухсторонний OAuth.)
Если речь идет только о сервер-серверная связь, я бы подумал об использовании авторизации на основе ключа API - как в bit.ly или FriendFeed.
Greg:
I have been working on an extension to the OAuth core that I think may answer you need. We wanted to write applications against our own API, but we felt it did not make much sense to not allow our own applications (As the service provider) to collect credentials directly from the user / consumer application - since we already would be considered a trusted party to ourselves.
The extension allows for 1st, 2nd, and of course 3rd party (traditional OAuth), while using the security of tokens and secrets, and signing, etc... that the Protocol provides.
Our beta documentation on the extension can be found here.
Фактически существует две спецификации OAuth: трехсторонняя версия и двухсторонняя версия. Трехсторонняя версия привлекает наибольшее внимание.
Двухсторонняя версия делает именно то, что вы изначально хотите, она позволяет приложению предоставлять доступ другому через общий секретный ключ (очень похожий на Amazon Модель веб-службы, вы будете использовать метод подписи HMAC-SHA1) или через систему открытого / закрытого ключа (используйте метод подписи: RSA-SHA1). Плохая новость заключается в том, что он еще не так хорошо поддерживается, как трехсторонняя версия, поэтому вам, возможно, придется проделать немного больше работы, чем вам, возможно, пришлось бы прямо сейчас.
По сути, двухсторонний OAuth просто определяет способ «подписать» (вычислить хеш) несколько полей, которые включают текущую дату, случайное число, называемое «nonce», и параметры вашего запроса. Это делает очень сложным олицетворение запросов к вашей веб-службе.
OAuth медленно, но верно становится общепринятым стандартом для такого рода вещей - в долгосрочной перспективе вам будет лучше, если вы принять его, потому что люди могут затем использовать различные библиотеки, доступные для этого.
Заставить работать одновременно и двуногих, и трехногих, сейчас довольно сложно, но это возможно (в Google это работает прямо сейчас) . http://code.google.com/apis/accounts/docs/OAuth.html