A common situation is that the eSignAnyWhere user is redirected to a custom web application which should deal with the envelope sent before via eSignAnyWhere Web UI. To access the envelope via API, the custom web application must authenticate to the API with a user that has the permission to access the envelope. While this was difficult in the past and often required to keep records of a mapping of envelopes to the creator, this got much simpler since eSignAnyWhere supports the OAuth2 Code Grant authentication flow. The user of the custom web application is asked to authenticate, via OAuth2, with the eSignAnyWhere user credentials. As a result, a code sharing between eSignAnyWhere and the custom web application is triggered and as a result the custom web application gets API credentials to access the envelope. During authentication, the user may choose the wrong user account on eSignAnyWhere – therefore it is required to check the permissions for the envelope, and redirect to the authentication again if the authentication provided does not have the required permissions.
Sample sequence diagram of a sample application we implemented for DMS tagging: ![DMS_9.png](/plugins/servlet/confluence/placeholder/unknown-attachment?locale=en_GB&version=2) Note that the invocation of the tagging page cannot contain the "envelopeId" as HTTP GET parameter, as GET parameters are not allowed in the OAuth 2.0 redirect_uri. This is because the OAuth application configuration in eSignAnyWhere AdminWeb must already be whitelist the full URL including all parameters. Therefore, the sample application we implemented is encoding all GET arguments from first call into the “state” parameter of the authentication call. The redirect_uri is invoked with the state parameter, as specified in RFC 6749. So the state is used in that case to transport all the GET parameters. The callback handler implementation also requires to know the API Token (Bearer Token) of the sender to retrieve signed documents, audit trail etc. – therefore the DMS Tagging Page implementation is already storing a mapping between envelopeId and senderUser and also a bearertoken of the senderUser in its persistent storage. |