Токены доступа для длительных задач - PullRequest
0 голосов
/ 07 октября 2019

Гипотеза такова: :

Внешнее приложение запрашивает аутентификацию, используя неявный поток, и пользователь входит в систему. Приложение предлагает пользователю функциональность для создания задачи / задания, которое должновыполнить ряд вещей в запланированный момент в будущем и от имени пользователя. Это также может быть длительной задачей, охватывающей часы (даже дни). Внешнее приложение имеет свой собственный идентификатор клиента (с неявным потоком), а служба, выполняющая запланированное задание, имеет отдельный идентификатор клиента (и секретный).

Вопросы:

  • Что интерфейсное приложение должно передать запланированной задаче, чтобы служба, выполняющая запланированную задачу, могла аутентифицироваться как исходный пользователь?

  • Предполагая, чтоЗадача должна работать с токеном обновления, чтобы при необходимости она могла получать новые токены доступа. Как она может получить токен обновления в первую очередь? Приложение переднего плана не может передать первый, так как токены обновления не поддерживаются в неявном потоке, и оно будет выдано не тому клиенту, даже если оно было поддержано.

1 Ответ

0 голосов
/ 10 октября 2019

Хорошей идеей будет посмотреть на делегирование. С этой концепцией ваш сервис может получить новый токен, который идентифицирует себя как пользователя, но с особым утверждением «действие», которое идентифицирует сервис. https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16

У сервера идентификации больше нет этого по умолчанию в версии 4, но есть несколько примеров того, как добавить его обратно. Этот случай будет довольно простым, так как вы сказали, что можете доверять своемусервис, так что все, что вам действительно нужно, это сообщить IdentityServer, что клиенту разрешено выдавать себя за любого. Вот пример https://www.daimto.com/identity-server-4-user-delegation/

...