Archived Forum Post

Index of archived forum posts

Question:

oauth2 custom URI

Oct 10 '17 at 08:23

I've been taking a look at your oauth2 C++ component and have one question about the redirect portion. I have no issues redirecting to http://localhost:port. I'm wondering if there is support for redirecting to a custom URI like myapp:/callback? I've tried plugging in various combinations into put_LocalHost() but it looks like Chilkat automatically adds http:// to whatever is added to that field. I think I could modify the resulting URL to suit but was wondering if I can avoid the extra step. I'd appreciate any info you can provide. This is a great product.

Thanks!


Answer

Thanks!

I don't understand how that would work. The 3-legged OAuth2 requires a browser to be displayed with a URL visited to interactively obtain Yay/Nay from the account owner. The HTTP response from the OAuth2 provider would be a redirect, and the browser would then redirect to it -- which is to send the HTTP request to the Chilkat background thread behaving as a "web server". This is how the access token is obtained.

Given the flow, it must be a "http://localhost:port/" because it must be a request sent to Chilkat running in the background thread. That's what completes the 3-legged OAuth2.

If the redirect was to myapp:/callback, then (1) I don't see how the browser would handle it, and (2) the Chilkat background thread would be left hanging and the application would never receive the access token.


Answer

Oauth2 component supports redirect to https??


Answer

The Chilkat OAuth2 class is to help desktop and non-web applications with 3-legged OAuth2.

If you have a web application, then you would implement the 3-legged OAuth2 directly. In 3-legged OAuth2, you have (1) an Authorization Endpoint, and (2) a Token Endpoint.

For example, in Shopify:

In a web application, you would use Chilkat Http or any other convenient HTTP API to send the initial request to the Authorization Endpoint. Your redirect_uri would be a URI directed back to your web application, which receives the redirect request and then sends the final HTTP request to the token endpoint.

HTTPS (i.e. a secure TLS connection) SHOULD be used in the case of a web application, because the redirect is traveling from the local browser, across the Internet, to your web application.

In the case of a desktop application (non-web application), you don't have the capability to receive a redirect on a web server. The Chilkat OAUth2 class is creating a background thread for the single purpose of receiving the redirect. Thus the local web browser that interactively gets permission from the account owner is always communicating with your application on the same local machine. There is no communication across the Internet for the redirect, and therefore no HTTPS is needed. In fact, you cannot really use HTTPS because what server certificate would you use? You'd run into all sorts of trust issues with the browser not being happy with some self-signed "localhost" certificate. There's just no point in opening that can of worms because it's not even necessary..