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.

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.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.