#docusignapi
Вопрос:
У меня есть приложение DocuSign, которое использует «Предоставление кода аутентификации» для отдельных пользователей для создания и отправки конвертов и использует «Предоставление JWT» для опроса и загрузки подписанных документов (т. Е. Автоматизированные операции, как описано в документации).
Все примеры и документация, с которыми я сталкивался, похоже, сосредоточены на использовании учетной записи администратора/системы для предоставления JWT и, в частности, для олицетворения пользователей. Мне вообще не нужна функция олицетворения пользователя.
В настоящее время я использую обычного (не являющегося администратором) пользователя, которому назначен пользовательский профиль разрешений. Профиль прост, только с отметкой «Разрешить просмотр и управление правами на конверты через API«. Это работает в песочнице разработчиков. У меня нет проблем с опросом или извлечением документов с этим пользователем и предоставлением JWT.
- Допустимо ли использовать пользователя, не являющегося администратором, для предоставления JWT, как в данном случае?
- Может ли кто-нибудь указать мне документацию, касающуюся использования JWT Grant для автоматизированных процессов, которые не требуют интенсивной интеграции или доступа на уровне администратора?
Ответ №1:
- Да, это приемлемо, я не знаю ни одной причины, по которой этого не будет.
- Это руководство по рекомендациям JWT в центре разработчиков DocuSign. Не знаю, что еще вам может понадобиться, но не стесняйтесь задавать конкретные вопросы.
Ответ №2:
Да, вы можете использовать поток предоставления JWT для выдвижения себя за пользователей учетной записи, которые не являются администраторами. Это распространенный вариант использования гранта JWT.
Комментарии:
1. Понял. Казалось, что это было бы достаточно распространенным явлением, но я не совсем понимал это. Большая часть документации по гранту JWT, похоже, больше ориентирована на более крупные интеграции или на те, которые требуют олицетворения для нескольких пользователей.