Мы находимся на ранних этапах разработки RESTful / ресурсо-ориентированного API веб-службы для приложения вычислительной лингвистики. Поскольку многие ресурсы, которые мы планируем обслуживать, ограничены правами, ключевым дизайнерским решением было указать платформу, чтобы каждый поставщик ресурсов мог предоставлять свою собственную веб-службу, соответствующую спецификации API. Таким образом, правообладатель сохраняет контроль над своим контентом (и, следовательно, возможность ограничивать или запрещать доступ по своему желанию) и поддерживать прямые отношения с потребителем, сохраняя при этом возможность участвовать в совместной сети.
В то же время, чтобы упростить задачу по написанию клиента для этой службы, мы хотим разрешить клиенту доступ к распределенной службе через одну конечную точку, при этом сервер будет обрабатывать согласование контента и его получение от соответствующих поставщиков.
Прямо сейчас мы зашли в тупик по поводу схем аутентификации / авторизации. Один из наших аргументов выступает за (техническую) простоту центрального реестра аутентификации, но другие обеспокоены организационной сложностью такой схемы.
Мне кажется, что на основе хотя и ограниченного понимания технологий, комбинация OpenID и OAuth сработает, когда клиент будет аутентифицироваться с конечной точкой через OpenID, а сервер будет действовать от имени пользователя с помощью различные поставщики контента, использующие OAuth.
Я когда-либо видел только реализации (например, stackoverflow, twitter и т. Д.), В которых присутствовал человек, чтобы вмешаться, и мне все еще нужно провести дополнительные исследования этих технологий.
Будет ли подобная схема работать для автоматизированной веб-службы или это сделает клиента слишком сложным для реализации и эксплуатации?
