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.

Anonymous
  • We are working on expanded OAuth 2.0 support.

  • Is it possible to use OAuth2 without the need to use username and password, as in most of the other systems such as Salesforce, Microsoft Dynamics, Hubspot, Zoho, Zoom, etc.? OAuth has been made in order to not reveal credentials, hence requiring it makes it kind of useless.

  • Thank you Matt for the quick feedback. I appreciate.

    What we are trying to achieve is to be able to extract data from different organizations. The idea was to create a Connected App on our side which will then be the interface with our tenants.

    Correct me if I am wrong, but SAML will work only on 'our' Organization (and, as a side detail, my organization would need to have an Okta or G-Suite or Active Directory account).

    It seems to me our scenario is not reachable so far (unless we get the credentials for our customers), but please let me know if I am wrong. Else, if I am right, do you think in the near future SugarCRM will be able to have an Oauth with grant type 'authorization_code' instead of 'password'.

    Kind regards,

  • We recognize the limitations of the resource owner password credentials OAuth grant that we support today. We are looking at supporting other OAuth grant types (like the 3 legged grant types) in the future. For end users, using SAML web single sign on is an option that Sugar supports today to prevent credentials from being exposed to any other system than the identity provider.

  • Is it possible to use OAuth2 without the need to use username and password, as in most of the other systems such as Salesforce, Microsoft Dynamics, Hubspot, Zoho, Zoom, etc.? OAuth has been made in order to not reveal credentials, hence requiring it makes it kind of useless.