Member Avatar for Dani

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
  • 312 Views
  • 19 Hours Discussion Span
  • Latest Post Latest Post by Dani
Member Avatar for Dani

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.