The Sugar REST API adds support for OAuth 2.0 bearer tokens in Fall '18

You’ve been asking for it.  We’ve been listening.

We're improving our support of OAuth 2.0 standards by adding support for RFC 6750 bearer tokens in the Sugar Fall ‘18 release.  

So what's changing?  You’ll still authenticate to get the access token the same way.  For example, you might authenticate with a call similar to the following:

curl -X POST \
  https://mysugarinstance/rest/v11_3/oauth2/token \
  -d '{
   "grant_type":"password",
   "client_id":"sugar",
   "client_secret":"",
   "username":"admin",
   "password":"asdf",
   "platform":"base"
}'

And get something like the following in the response body:

{
    "access_token": "37cfa546-055b-43c9-8273-466fbf4b3235",
    "expires_in": 3600,
    "token_type": "bearer",
    "scope": null,
    "refresh_token": "671d8117-c8b7-4dee-92d6-4f309d717090",
    "refresh_expires_in": 1209600,
    "download_token": "eeb702a9-ec35-4a92-9619-d914172b5eac"
}

In versions prior to the Sugar Fall ‘18 release, you would include the access_token you received in response to the authentication call as an OAuth-Token in the header of subsequent requests.  For example, if you wanted to get a list of the Accounts, you would make a call like the following:

curl -X GET \
  https://mysugarinstance/rest/v11_3/Accounts \
  -H 'OAuth-Token: 37cfa546-055b-43c9-8273-466fbf4b3235'

Beginning in Sugar Fall ‘18, you can now follow OAuth 2.0 standards and pass the access_token as a Bearer Token.  Following the same example as above where we retrieved a list of the Accounts, you can now make a call like the following:

curl -X GET \
  https://mysugarinstance/rest/v11_3/Accounts \
  -H 'Authorization: Bearer 37cfa546-055b-43c9-8273-466fbf4b3235'

The difference is small.  You’re still passing an access token in the header of each request--you’re just changing the format of that header.  

So why are we making this change?  If you have integrated with other OAuth 2.0 resources, you’ll be able to reuse more of that code and/or behavior.  This change also enhances the interoperability of our APIs with standard tools and libraries. Plus, following industry standards is always a good thing.