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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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