Двухногий OAuth - поиск информации

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

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

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

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

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

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

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

25
задан Peter Mortensen 22 August 2012 в 19:37
поделиться

3 ответа

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

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

2
ответ дан Evert 28 November 2019 в 20:38
поделиться

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

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

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

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

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

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

Удачи!

48
ответ дан abraham 28 November 2019 в 20:38
поделиться

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

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

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

Вы не хотите пытаться обеспечить «никогда не истекающий» сеанс, так как:

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

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

  3. Поскольку вы знаете, что хотите добавить дополнительные типы имен входа в будущем, вместо двух типов имен входа (серверные клиенты и клиенты браузера), сделайте только один тип входа в систему сейчас. Дополнительная работа для клиентского сервера будет заключаться в реализации возможности «повторного входа в систему по мере необходимости».
5
ответ дан Peter Mortensen 28 November 2019 в 20:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: