Двусторонний OAuth - ищет информацию

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Спасибо, что помогли найти ответ, хотя..

Ответ 2

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

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

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

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

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

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

Удачи!

Ответ 3

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

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

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

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

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

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

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