Как использовать OpenID в RESTful API?

Ответ 1

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

Итак, вопрос можно разделить на две части,

• Как сделать аутентификацию OpenID через API
• как я могу сохранить состояние "аутентифицированного" в последующих запросах.

Для первой части аутентификация OpenID почти всегда включает интерактивные шаги. Во время процесса аутентификации скорее всего будет шагом, когда пользователь находится на веб-странице поставщика OpenID, выполнив вход и нажав кнопку "Я согласен". Поэтому API не может и не должен обрабатывать это прозрачно (нет "скажите мне ваш провайдер OpenID и пароль, и я сделаю все остальное" ). Лучшее, что он может сделать, это передать и вернуть HTTP-ссылки, которые клиент должен открыть и следовать инструкциям.

Поддержание "аутентифицированного" состояния

API REST должен быть без гражданства, каждый запрос должен содержать всю информацию, необходимую для его обработки, не так ли? Для каждого запроса не имеет смысла аутентифицировать провайдера OpenID, поэтому необходим какой-то сеанс. Некоторые из параметров обмена ключом сеанса (или "токеном доступа" или именем пользователя/паролем):

• HTTPS + BASIC аутентификация (заголовок "Авторизация: основной..." в каждом запросе)
• Подписывание запросов Амазонский стиль (заголовок "Авторизация: AWS..." в каждом запросе)
• OAuth: получить токен доступа, включить это и кучу других параметров в каждом запросе
• Cookie, в котором хранится ключ сеанса (заголовок "Cookie:..." в каждом запросе)
• Подписанный файл cookie, который хранит информацию о сеансе в самом файле cookie

Сейчас только один пользователь API, поэтому я решил пойти на самую простую вещь, которая могла бы работать - файлы cookie. Они очень просты в использовании в Pylons, с помощью Beaker. Они также "просто работают" в приложении Flash, так как он работает внутри браузера, браузер будет включать в себя соответствующие файлы cookie в запросах, которые делает приложение для Flash, - приложение не нужно вообще изменять по отношению к этому. Здесь один вопрос StackOverflow, который также защищает использование файлов cookie: Аутентификация RESTful для веб-приложений

Beaker также имеет приятную особенность сеансы cookie, где все данные сеанса содержатся в самом файле cookie. Я предполагаю, что это примерно так же, как и без гражданства. На сервере нет хранилища сеансов. Файлы cookie подписываются и, возможно, зашифровываются, чтобы избежать их несанкционированного доступа на стороне клиента. Недостатком является то, что cookie становится немного больше, поскольку теперь ему нужно хранить больше, чем просто ключ сеанса. Удалив некоторые вещи, которые мне действительно не нужны в сеансе (остатки от проверки OpenID), я получил размер файла cookie примерно до 200 байт.

Ответ 2

OAuth лучше подходит для использования API. Вот пример использования OAuth в Python: oauth-python-twitter. Leah Culver python-oauth библиотека - это каноническая реализация OAuth в Python, но python-oauth2 является недавним соперником, который получает некоторый шум. Что касается вдохновения, django-piston поддерживает использование OAuth для создания auth при создании RESTful API для Django, хотя документация не такая приятная как я хотел бы для этой конкретной темы.

Ответ 3

Если вы создаете API, вы можете проверить протокол OAuth. Это дополняет OpenID.