2

This was posted in a behind-the-scenes forum yesterday, but here it is for everyone today:

There have been a LOT of changes so far, and more to come. Most of what's happened so far has dealt with OAuth. A lot more security on the backend and more in line with standards.

For the most part, the changes have been transparent, but there are a few things I'll bring to your attention.

Firstly, as you know, the end user authorizes the application and gives you a code. You can then exchange that code for an access_token. One of the changes is that in the past you could store the code and keep exchanging it for new access_tokens when they expire. Not anymore.

Keeping in line with standards, when you exchange a code, you're now given both an access_token and a refresh_token. You can only exchange the same code once, and then it stops working, but you can use the refresh_token to acquire new access_tokens when they expire. Unlike with the OAuth flow used to exchange code for an access_token, using your refresh_token to retrieve an access_token can be done offline (i.e. via your own backend script at any time without end-user intervention or browser access). This opens up lots more possibilities since you now have the ability to authenticate as the end-user without the end-user being near their browser.

The second big change, thanks to Sanjay, is that the serverside OAuth implementation now allows for a desktop flow, which should make it painless to write desktop applications now taking advantage of OAuth!! Looking forward to all the amazing things that are going to come from this.

1
Contributor
1
Reply
27
Views
4 Years
Discussion Span
Last Post by Dani
1

There's been some confusion about the flow, so here goes:

  • Send the end user to /api/oauth and receive a code
  • The code is one-time use; Exchange the code for a refresh token and an access token
  • All access tokens always last for only 24 hours
  • Store the refresh token on your end, and at any time, you can exchange it for a new access token

Nothing should be breaking the flow of existing apps, where you send the end user to /api/oauth, receive a code, and exchange it for an access token. If you keep sending the user to /api/oauth and getting a new code and a new first-use access token, then fine, that works for web-based apps.

The new advantage here is that, once receiving authorization from the end-user, the refresh token->access token exchange does not do any browser redirects or require anything on behalf of the end-user, you can have a perpetually working access token that can do things via cron jobs, etc.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.