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