REST-аутентификация / авторизация с использованием федеративных удостоверений JWT
Я смотрю на разработку приложения, которое предоставляет сервисы с использованием REST. Эти услуги будут доступны через браузерные и не браузерные клиенты. Я ожидаю, что будет несколько установок этого программного обеспечения, которые принадлежат и управляются различными группами. Я хочу разрешить пользователям из одной системы получать доступ к службам в другой. Они не будут использовать один и тот же магазин идентификации. Мне бы хотелось, чтобы пользователь мог аутентифицироваться в своем экземпляре, а затем использовать токен для отправки запросов своему экземпляру и удаленным экземплярам. Это похоже на хорошее использование для JSON Web Tokens (JWT). Каждая система должна быть настроена на доверие друг к другу токенов, которые подписаны сертификатами.
Я читал, что это можно сделать с помощью OAuth с токенами JWT Bearer, но это выглядит как дополнительная нагрузка, чем необходимо. Зачем менять токен носителя на токен доступа, а не просто использовать токены носителя? Я подвергаю сомнению, подходит ли OAuth, независимо от того, потому что он не контролирует, может ли система получить доступ к данным пользователя в другом месте, как, например, во многих примерах в Интернете, но имеет ли пользователь доступ к данным, хранящимся в системе.
Следующая часть проблемы заключается в определении того, как создавать эти токены JWT, кажется, что что-то вроде WS-Trust STS подойдет. Я не видел ни одного простого и просто аутентифицирующего пользователя и возвращающего токены. Потенциально может быть полезно также иметь поддержку для продления срока действия токена и проверки токенов?
В прошлом я мог включить этот тип возможностей, используя SOAP с WS-Security и SAML Assertions. Я хочу посмотреть, можно ли сделать то же самое с помощью токенов REST и JWT. В Интернете есть много постов, в которых не рекомендуется использовать собственную систему безопасности, поэтому я не решался двигаться вперед. Я видел, что Microsoft добавила обработчики для защиты служб, использующих токены JWT, поэтому кажется, что они видят некоторую ценность в этом подходе.
Есть ли у кого-нибудь понимание способов реализации такого рода федерации удостоверений для служб REST стандартным и простым способом?
1 ответ
Да, именно такой подход я рекомендую своим клиентам. Фактически, JWT - это то, как Windows Azure Mobile Services защищает свои конечные точки. JWT относительно прост в обращении (по сравнению с токенами SAML, например), но сохраняет интересные свойства по сравнению с access_tokens (как с подписью).
В этом документе показан пример того, как это сделать с помощью WebApi и нашего продукта (если вы используете технологии MS). Однако эти принципы являются общими, и вы можете применять их независимо от того, используете вы наши STS или нет.