I'm trying to implement the Implicit Grant REST API of DocuSign. I'm confused as to what needs to happen right after the user logs in. This is a stand-alone native Windows desktop application, not a web service or page.
I got as far as to open an embedded browser window, navigating to the correct URI for login, and the user is able to successfully login. I further have an HTTP server running in this application as well which is to receive the callback. In fact, the callback does work, I do get an incoming HTTP GET command. However, there is nothing usable in this callback response. No special headers, parameters, body, nothing.
Before I tried the Implicit Grant API, I first tried the JWT Grant method, before realizing it wasn't the right approach. But my point is, at least I had a code parameter in the callback command. But after shifting over to use the Implicit Grant method, this response is empty.
According to the documentation:
After consent has been granted, the Authentication Service verifies that the client application is valid and has access to the requested scope. If so, it redirects the access token to the provided callback URI in a hash fragment.
The response contains the following hash fragment parameters:
.......
It even shows an example response:
http://localhost/#access_token=eyJ0eXAi.....9LyiFrUqvdw&expires_in=28800&token_type=bearer&state=a39fh23hnf23
But, as mentioned, the callback response I receive has nothing of notable value. It's essentially just empty.
What am I missing here? What's the correct approach to complete the authentication process and proceed to actually using the API?
NOTE: I'm using Delphi, so none of the examples provided by DocuSign are compatible.
I discovered what I was doing wrong. It was some confusion and terminology mix-ups. When I stated that my callback URI does in fact work, that's in reference to it triggering my HTTP server listening from within the app - but had no usable data.
However, what I actually need to do is not capture the request in the HTTP server, but rather catch the URI that the embedded browser navigates to after user authentication. Once I sniffed into this browser's URI after successful login, now I can in fact see access_token.
So callback uri and redirect uri are the exact same thing, but can be easily misinterpreted. I kinda have two different definitions of them, where callback is to respond to original caller, and redirect means to navigate from one page to another automatically.
Now I'm curious whether I should even need an HTTP server, or if I could just blindly throw any arbitrary redirect URI (of course registered in the account) and just grab the URI after the embedded browser navigates.
As to why my HTTP server didn't see this data, but the embedded browser did, is beyond me. It should match in both sides.
Just for reference, the embedded browser I'm using is Chromium (DCEF3), and the HTTP server is Indy's TIdHTTPServer component.
UPDATE
As noted in the comments, the HTTP Server does not receive the "bookmark" portion of the URI by design, because the bookmark is a client-side only thing. There's no reason at all why it should ever be sent to the server. Hence the level of security - since that information will ONLY be used by the client, and not the server, it would be risky to send the access_token to the server, over the web. So it keeps it local to the client-side browser. That's why I saw this data on the browser, and not the HTTP server request handler.