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

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

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

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

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

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

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

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

[Курсив добавлен]

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

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

Я обнаружил, что делаю не так. Это была путаница и путаница в терминологии. Когда я заявил, что мой 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-сервера.

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