Я потратил некоторое время на изучение вариантов и хотел бы подвести итоги.
Во-первых, немного больше контекста - я разрабатываю и контролирую как сервис, так и пользователя API. Потребитель - это приложение на основе Flash, которое обслуживается с того же хоста, с которым сейчас работает API, и предполагается, что оно будет использоваться в браузере. Сторонних клиентов пока не видно.
Так что вопрос можно разделить на две части,
- как мне выполнить аутентификацию OpenID через API
- как мне поддерживать "аутентифицированное" состояние в последующих запросах
Для первой части аутентификация OpenID почти всегда включает в себя интерактивные шаги. В процессе аутентификации, скорее всего, будет шаг, когда пользователь находится на веб-странице провайдера OpenID, войдет в систему и нажмет какую-нибудь кнопку «Я согласен». Таким образом, API не может и не должен обрабатывать это прозрачно (не «сообщите мне ваш поставщик OpenID и пароль, и я сделаю все остальное»). Лучшее, что он может сделать - это передавать и возвращать HTTP-ссылки, которые клиент должен открывать, и следовать инструкциям.
Поддержание "аутентифицированного" состояния
API REST должны быть без сохранения состояния, каждый запрос должен включать всю информацию, необходимую для его обработки, верно? Не было бы никакого смысла проходить аутентификацию у провайдера OpenID для каждого запроса, поэтому какой-то вид сеанса необходим. Некоторые параметры для связи сессионного ключа (или «токен доступа» или имя пользователя / пароль):
- HTTPS + BASIC-аутентификация (заголовок «Authorization: Basic ...» в каждом запросе)
- Подписание запросов Amazon-style (заголовок «Авторизация: AWS ...» в каждом запросе)
- OAuth: получить токен доступа, включить его и кучу других параметров в каждый запрос
- Cookie, в котором хранится сеансовый ключ (заголовок «Cookie: ...» в каждом запросе)
- Подписанный файл cookie, который хранит информацию о сеансе в самом файле cookie
Сейчас есть только один потребитель API, поэтому я решил пойти на самую простую вещь, которая могла бы сработать - куки. Они очень просты в использовании в пилонах, с помощью мензурки . Они также «просто работают» в приложении Flash - поскольку оно запускается внутри браузера, браузер будет включать соответствующие файлы cookie в запросы, которые выполняет приложение Flash, - приложение вообще не нужно изменять в этом отношении. Вот один вопрос StackOverflow, который также рекомендует использовать куки: RESTful-аутентификация для веб-приложений
В Beaker также есть замечательная функция сеансов только для файлов cookie , где все данные сеансов содержатся в самом файле cookie. Я думаю, что это примерно так же, как и без гражданства. На сервере есть нет хранилища сессий. Cookie-файлы подписаны и при желании зашифрованы, чтобы избежать подделки на стороне клиента. Недостатком является то, что cookie становится немного больше, поскольку теперь ему нужно хранить больше, чем просто ключ сеанса. Удалив некоторые вещи, которые мне действительно не нужны в сеансе (остатки от аутентификации OpenID), я уменьшил размер куки до примерно 200 байт.