Page History

Authorization Request

Then the user is redirected to the configured redirect page. Whatever custom page should be used, it must return with an HTTP Redirect to that OAuth2 authorization page of eSignAnyWhere when authorization is unknown or invalid (URL is typically https://<esaw-instance>/Auth/Authorize - read below for necessary parameters). E.g. in case of authenticating for a tagging page, the tagging page implementation ensures that the authentication is done first (redirect to authentication, and return to tagging after authentication was passed). If the "beforeSendRedirectUrl" is used solely for authentication, but no specific data input is necessary, an "empty dispatcher page" may be used instead.

If the user is not yet logged in, the Authorize page would start with the standard eSignAnyWhere login form.
As in the context of sending a draft the sender is already authenticated, no login form is shown.

On first usage, the app asks for permissions to grant API access. The user therefore has to give consent in following approval form provided by eSignAnyWhere as part of the OAuth2 Authentication steps:

The name shown in the consent approval form (int the example: "XXXXX DMS tagging service") is part of the configuration of the eSignAnyWhere OAuth Application, so configured centrally per instance in the AdminWeb.

After the consent form was completed (or immediately, in case consent was already approved before), the Authorize page redirects via HTTP 302 to the redirect_uri provided in the GET parameters.
Note that the redirect_uri must be added to the allowlist in the AdminWeb configuration therefore.

In case of using the beforeSendRedirectUri for tagging, the 302 target can be the tagging page. See Document Tagging Scenario - Example showing how to collect metadata for DMS archiving for details.
If using the beforeSendRedirectUri solely for the purpose to collect a bearer token for later usage in a callback handler, the mentioned "empty dispatcher page" could do the following:

• implement the token retrieval in the backend, and store reference envelopeId→senderUser and senderUser→bearerToken
• use draft/send to send the envelope finally
• instead of displaying a tagging page, directly proceed with HTTP 302 to the document inbox