Блог

Поэтому, если у меня есть приложение с большим количеством пользователей на борту, все из разных компаний/мест, я думаю, что индивидуальное «подключение к docusign» с помощью OAuth-это правильный подход.

Я думаю, что я мог бы попросить администратора подключить свою учетную запись и выдать себя за всю компанию, но это звучит не очень хорошо с точки зрения безопасности.

Я также вижу, что некоторые места просят людей ввести имя пользователя/пароль администратора docusign, что, как я полагаю, крайне не рекомендуется.

Вопрос: Я планирую использовать только одну «интеграцию» для своего приложения, чтобы управлять всем этим, должен ли я стремиться использовать одну интеграцию для каждой учетной записи docusign, с которой я взаимодействую? т. Е. Должен ли я попросить компании сделать интеграцию и предоставить мне идентификатор/секрет?

Несколько вопросов здесь:

Поток OAuth

Да, если у ваших пользователей DocuSign будут свои собственные идентификаторы пользователей DocuSign, вы можете добавить кнопку «Подключиться к DocuSign» и использовать поток предоставления кода авторизации OAuth. Включите extended область, чтобы вы могли использовать маркер обновления на постоянной основе. Не забудьте использовать безопасное энергонезависимое хранилище для токенов обновления, так как их можно использовать для получения токенов доступа.

См. раздел Проверка подлинности для ISV

Я думаю, что я мог бы попросить администратора подключить свою учетную запись и выдать себя за всю компанию, но это звучит не очень хорошо с точки зрения безопасности.

Правильный. Лучше всего использовать грант JWT (олицетворение) только в том случае, если конечные пользователи не могут использовать поток предоставления кода авторизации. Например, если ваше приложение является внутренним приложением или не имеет веб-интерфейса.

Поток JWT (олицетворение) хорош, когда это необходимо, но он вызывает значительную путаницу у клиентов и требует работы по предоставлению согласия. Поэтому предоставление кода авторизации предпочтительнее, если он соответствует вашим потребностям в качестве ISV.

Один идентификатор клиента docusign_id (ключ интеграции) или один для каждого конечного клиента?

Лучше всего использовать один идентификатор клиента DocuSign (ключ интеграции) для вашего приложения, а не по одному на каждого клиента. См. Документы ISV

Должен ли я попросить клиентов предоставить мне ключ интеграции и секрет, которые они создали?

Пожалуйста, нет. Ваши клиенты не являются разработчиками. Попросить их стать разработчиками DocuSign и создать идентификатор клиента (ключ интеграции) — это для них большая работа. Нет необходимости идти по этому пути. Просто используйте один и тот же код авторизации OAuth redirect_uri для всех ваших клиентов. Помните, что вы можете использовать этот state параметр по мере необходимости для обработки перенаправления OAuth из DocuSign.

Используйте свою бесплатную партнерскую учетную запись для manage идентификации клиента вашего приложения и его настроек.

запрос имени администратора DocuSign/pw от ваших клиентов

Правильно: не делай этого!

вы хотите, чтобы ваши клиенты настраивали свои учетные записи DocuSign определенным образом

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

пользователи имеют несколько учетных записей

Дополнительно: помните, что клиенты DocuSign обычно имеют доступ к нескольким учетным записям DocuSign. Например, общий счет, счет отдела кадров и т. Д. Они могут создать или не создать специальную учетную запись для вашего приложения, в зависимости от варианта использования.

После аутентификации пользователя ваше приложение может либо использовать учетную запись пользователя по умолчанию, либо, если ваше приложение использует специальную учетную запись, убедитесь, что у пользователя есть доступ к ней.