Digging Deeper into OAuth 2.0 at Salesforce.com

OAuth Roles OAuth (an abbreviation of open authorization) is an open protocol which allows secure authorization of desktop and web applications to access APIs. A commonly used analogy is the valet key to a car, which allows the car to be driven (perhaps a limited distance), but does not give access to the glovebox or trunk. In the same way, OAuth allows users to authorize applications to access resources on their behalf via an access token, rather than by handing over their actual username and password.

Jeff Douglas‘ article last summer, Using OAuth to Authorize External Applications, covers the 1.0a version of the protocol (aka RFC 5849) that has been supported in the Force.com platform since Winter ’10, but the world moves quickly, and Winter ’11 saw the introduction of OAuth 2.0 to Force.com. My article of a few months ago, Getting Started with the Force.com REST API, covered the basics of authorizing API access via OAuth 2.0, but deliberately stayed out of the darker passageways.

Now, Digging Deeper into OAuth 2.0 at Salesforce.com really shines a light on our implementation of the protocol, examining the different flavors of token, walking through the flows in detail and introducing the Identity Service, a RESTful equivalent to the SOAP API’s getUserInfo(). Prepare a cup (or mug, or glass) of your favorite beverage and join my guided tour of OAuth 2.0

tagged Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • forfor and

    Getting Started with the Force.com REST API example doesn’t work. It breaks after successful authorisation and getting the callback when it is supposed to print to the screen the data retrieved and modified.
    It complains about the LogFactory class not found:
    java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory

    java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
    at org.apache.commons.httpclient.HttpClient.(HttpClient.java:66)

    This happens even though I added commons-logging-1.1.1.jar to the classpath in WEB-INF/lib.

    Have no idea what’s wrong.

    • forfor and

      An error was caused because Tomcat was missing the logging libraries.
      I fixed the problem by adding either of the following to the TOMCAT_HOME/lib/ directory:


      • Good to see you got it working, and thanks for posting the answer!

        • forfor and

          Thank you very much for your tutorials.
          Regarding your ‘Getting Started’ tutorial it’s also worth noting that as of today the JSON site only provides JSON source code and so JSON lib has to be compiled. For the example to work one also needs to download apache commons-codec library.

          I would be very grateful if you would help me with another problem.
          I need to build a 3rd party client application that accesses my customer’s salesforce database to present them with some of their accounts data.
          Is there any way of authorizing and granting access to my client application to Resource Server without the need of initial interaction with the end user (owner of the database)?
          I reckon it’s not best way accessing my customer’s salesforce database with their private credentials which you described in “Digging Deeper into OAuth 2.0” as “Obtaining a Token in an Autonomous Client (Username-Password Flow)”.

          • Thanks for the tips on the JSON source and Apache commons-codec. I said in the article that you need to add the JSON.org code to your project – I’ll maybe make that more explicit. I’ll check out the commons-codec dependency too and write a note on that.

            Regarding your app, one option might be to ask the user for their credentials once, at setup, and store the resulting refresh token. Now, each time your app runs, it can exchange the refresh token for an access token. I’ve seen this done in a Node.js app, running a minimal web server and opening a browser window on localhost:8888; you could do something similar with Jetty in Java.

  • Dan Dennhardt

    Hi @Pat Patterson – I’ve heard some talk that the SAML assertion generated by PingFederate 6.5 doesn’t work with Salesforce and that an upgrade is necessary… Before I spend time investigating, I am wondering if you know if there is any truth to that?

    • Hi Dan – sorry I missed your comment. I hadn’t heard of any specific problems with PingFederate and Salesforce. Did you get it working?

  • Digging Deeper in OAuth 2.0 at Salesforce, was my reference material for building out an external chatter like button connecting to salesforce. You explained the OAuth dance in simple terms compared to other materials on the web. Thanks Pat.