OAuth Redirect URL for Desktop Applications

[nezzaby]

Hello.  We have a desktop application that has an integration with the Traditional APIs.  Currently, we obtain API tokens by logging in to the developer center, requesting a token, and having the user log in to their account.  We are now looking into using some new features in the RESTful APIs.  The Oauth token generated via the developer center for use with the RESTful APIs is very short lived and it doesn't appear to give us a refresh token.  So it looks like our users would have to use the eBay sign in page for granting access to our application.  However, this requires a callback URL that eBay calls with the authorization code that can then be used to request an access token and a refresh token from the API.  Because our application is a desktop application, we don't have a public facing API for creating a callback URL.  There doesn't seem to be a way for our application to immediately retrieve the authorization code.  Is that correct?  Am I missing anything that would allow us to obtain the access and refresh tokens without a public facing redirect URL?  Thanks!

[shipscript · Accepted solution]

The user of your program needs to log in only once for your application to generate a long-term user token. Your application must deal with the OAuth URL to obtain the user's initial authorization, and there is no way around that requirement. This token is short-lived (2 hours), but comes with a refresh token that can be used to continue refreshing the short-lived token for up to 18 months.  After that period, the user must again log in and grant access.

If you are not seeing the refresh token in your testing, make sure you are using the "authorization grant flow".

https://developer.ebay.com/api-docs/static/oauth-auth-code-grant-request.html 

https://developer.ebay.com/api-docs/static/oauth-refresh-token-request.html

[nezzaby]

Thank you so much for your response.  To confirm, when you say, "Your application must deal with the OAuth URL to obtain the user's initial authorization," you are referring to the redirect URL, correct?  In other words, there is no way to get the authentication code or the access token with the refresh token from developer.ebay.com directly?

Thanks again!

[shipscript]

That is correct. The user needs to log into their eBay account to grant access the first time the user signs up to your application. So, that first time (and once every 18 months) the user must log in through the website and you would retrieve the grant from the redirect URL's query string after the user accepts.

Because you can assign that redirect page (Your auth accepted URL) on your tokens page, your server should be able to capture the query string that is attached to the URL when that page is invoked, and then use that 5-minute token to acquire an access token and a refresh token. 

The flow is described here:

https://developer.ebay.com/api-docs/static/oauth-consent-request.html

However, that does not solve the problem of getting the token into a desktop application. It's been a long time since I had a desktop app that had to interface to the web over INET, so I'm behind on the safest strategies.

Since the refresh token requires some handshaking, I would assume one option is that the user tokens could reside on your server, to be accessed when your server is called by the desktop app to interface with eBay.

[nezzaby]

Thank you for your help!

[swiv-o-matic]

Last question first: no, you cannot obtain a refresh token from the API explorer or elsewhere on the website. You can obtain an OAuth User Token but it will only be valid for 2 hours. You must implement the OAuth grant flow in some form. You can do this in many different ways programmatically and none are as difficult as the documentation makes it out to be (more on this later).

Now the first question: The redirect URL is only one step of the OAuth. Once you complete this step (after logging in if necessary (if you aren't already) and then consenting to the permissions your app is requesting) you are given what's called a "consent token".  This consent token is then exchanged for a User Access Token and Refresh Token (they will be sent in the same JSON response). From here, you can use that initial User Access Token for 2 hours. Once that expires, you must use the Refresh Token to generate a new one. It's recommended you keep track of the refresh times locally and refresh the token prior to it expiring. 

Ultimately what's going on in the grant flow is this (simplified):

Your app concatenates your Client ID & Client Secret, base64 encodes them.

Takes a string of scopes you want authorization for.
URL encodes everything into a hyperlink which you either click or direct the user to.
The above is just basic string stuff, nothing fancy here whatsoever. There are libraries built-in for nearly every language to accomplish this.

User (signs in if needed) on said URL and accepts the permissions being asked for.
Site directs to your redirect URL where you capture the consent token.
You now make a call to exchange that token for your first User Access Token / Refresh token.

Alternatively, for the last steps you can do something like this (not recommended / not user friendly):
- don't specify a redirect URL on eBay. After the user consents, they will get a "thank you" page on eBay.
They will then copy the URL in the address bar which contains the consent token.
They can paste it into your app where you will parse the token from it. 
Then from there you would make the call to get the User/Refresh token.

They will have to do this every 18 months as that's when the consent expires, so you must track that as well.

There are many ways to pull this off. If you end up using a script on your website, please make sure all  credentials are stored outside of the webroot. This includes your Client ID/Secret, and the users' tokens. And it would be best to use some form of (at least) basic authentication to retrieve the credentials.

[nezzaby]

Hello.  That tip about the thank you page URL containing the authorization token is what I needed.  It didn't even occur to me that it would be appended to the default redirect page.  Agreed that it isn't user friendly, but it might do in a pinch.  Thank you!