DocuSign API - Как получить ответный ответ после аутентификации пользователя?

Question

Я пытаюсь реализовать API REST Implicit Grant для DocuSign . Я не понимаю, что должно произойти сразу после входа пользователя. Это автономное собственное приложение Windows для настольных компьютеров, а не веб-служба или страница.

Я дошел до того, чтобы открыть окно встроенного браузера, перейдя к правильному URI для входа в систему, и пользователь может успешно войти в систему. Кроме того, в этом приложении также работает HTTP-сервер, который должен принимать обратный вызов. На самом деле обратный вызов работает, я получаю входящую команду HTTP GET. Однако в этом ответе обратного вызова нет ничего полезного. Никаких специальных заголовков, параметров, тела, ничего.

До того, как я попробовал API Implicit Grant, я сначала попробовал метод JWT Grant, прежде чем понял, что это неправильный подход. Но я хочу сказать, по крайней мере, у меня был параметр code в команде обратного вызова. Но после перехода к использованию метода неявного предоставления этот ответ будет пустым.

Согласно документации:

После получения согласия служба аутентификации проверяет, что клиентское приложение является действительным и имеет доступ к запрошенной области. Если это так, он перенаправляет токен доступа к предоставленному URI обратного вызова во фрагменте ha sh.

Ответ содержит следующие параметры фрагмента ha sh:

..... ..

Он даже показывает пример ответа:

http://localhost/#access_token=eyJ0eXAi.....9LyiFrUqvdw&expires_in=28800&token_type=bearer&state=a39fh23hnf23

Но, как уже упоминалось, полученный ответ на обратный вызов не имеет ничего заметного значения. По сути, он просто пустой.

Что мне здесь не хватает? Как правильно завершить процесс аутентификации и перейти к фактическому использованию API?

ПРИМЕЧАНИЕ. Я использую Delphi, поэтому ни один из примеров, представленных DocuSign, не совместим.

Answer 1

Обновленный ответ Используйте Implict Grant, когда у не есть внутренний сервер как часть потока аутентификации. Неявное предоставление - в любое время, когда секретный идентификатор клиента / секретный ключ RSA не может быть защищен - в любом случае в архитектуре приложения отсутствует защищенный сервер. Это включает в себя мобильные приложения (поскольку приложение может быть реверс-инжиниринг, одностраничные приложения (React, Angular, et c) и настольные / толстые клиентские приложения (например, Delphi приложения).

Я использую Неявное предоставление для моих приложений DocuSign, которые я пишу в React.

В вашем случае вы пишете «приложение толстого клиента», которое полностью выполняется на рабочем столе.

Со времени потока неявного предоставления в DocuSign OAuth2 соответствует стандарту, хорошее место для начала - примеры платформы для аутентификации с другими провайдерами идентификации OAuth2.

Для Delphi см. их пример для Доступ к Facebook API . Хотя он не совсем совпадает с потоком неявного предоставления доступа DocuSign, он достаточно близок. В частности, обратите внимание, как Facebook также возвращает токен доступа во фрагменте URL при запросе response_type=token (как это делается в примере Delphi) .

Цитата из Facebook документы аутентификации :

response_type = token. Данные ответов включены в виде фрагмента URL и получает токен доступа. Настольные приложения должны использовать этот параметр для response_type. Это наиболее полезно, когда клиент будет обрабатывать токен.

[выделение добавлено]

Итог: используйте / измените Delphi пример аутентификации с Facebook, так как DocuSign является аналогичный. Если вы не можете заставить его работать, обратитесь за помощью в службу поддержки клиентов Delphi, ссылаясь на пример аутентификации Facebook.

PS После того, как вы решили проблему, предоставьте свой собственный ответ, включающий код, который вы использовать - помогать другим в будущем. Спасибо!

Answer 2

Я обнаружил, что я делаю неправильно. Это была путаница и терминологическая путаница. Когда я заявил, что мой URI обратного вызова на самом деле работает, это связано с тем, что он запускает прослушивание моего HTTP-сервера из приложения - но не имеет пригодных для использования данных.

Однако то, что я на самом деле нужно не захватывать запрос на HTTP-сервере, а перехватывать URI, к которому переходит встроенный браузер после аутентификации пользователя. После успешного входа в URI этого браузера после успешного входа в систему теперь можно увидеть access_token.

Так что callback uri и redirect uri - это одно и то же, но их можно легко неверно истолковать. У меня есть два разных определения, где обратный вызов должен отвечать на исходный вызов, а перенаправление означает автоматический переход с одной страницы на другую.

Теперь мне любопытно, нужен ли мне вообще HTTP-сервер или я мог бы просто слепо выбросить любой произвольный URI перенаправления (конечно, зарегистрированный в учетной записи) и просто захватить URI после навигации встроенного браузера.

Относительно того, почему мой HTTP-сервер не видел эти данные, а встроенный браузер это сделал, я не знаю. Он должен совпадать с обеих сторон.

Просто для справки, я использую встроенный браузер Chromium (DCEF3), а HTTP-сервер - компонент TIdHTTPServer Indy.

---

ОБНОВЛЕНИЕ

Как отмечено в комментариях, HTTP-сервер не получает часть «закладки» URI по своему дизайну, поскольку закладка является единственная вещь на стороне клиента. Нет никакой причины, почему он должен когда-либо отправляться на сервер. Следовательно, уровень безопасности - поскольку эта информация будет использоваться ТОЛЬКО клиентом, а не сервером, было бы рискованно отправлять access_token на сервер через Интернет. Таким образом, он остается локальным для клиентского браузера. Вот почему я видел эти данные в браузере, а не в обработчике запросов HTTP-сервера.

Answer 3

Implicit Grant в основном предназначен для мобильных приложений, для настольных приложений вам необходимо использовать Код авторизации , при таком подходе вы получите код обратно в RedirectUrl. Также обратите внимание на выбор опции Authorization Code Grant радио в конфигурации ключа интегратора.