Using OAuth

OAuth can be used to automatically log in users from your application into ours.

Remember to check out FastPass before going more into our OAuth implementation. FastPass is a simple Single-Sign On system where OAuth is already integrated.

Want to roll your own?

Here are the relevant URLs:

• Get a request token at /api/request_token
• Redirect users to /api/authorize?oauth_token=XXX to authorize a request token
• Exchange an authorized request token to get an access token at /api/access_token

Logging in a user using OAuth

Using this system you will be able to craft a special URL that will log a user into the appropriate Get Satisfaction account and redirect them on through to their destination. You could, for example, allow users of your system to link their accounts to our accounts so they don't need to login to Get Satisfaction when they want to ask a question about your service.

Overview of the steps

1. Getting an access token
   First you need to have your user grant access to act on their behalf. Using the normal OAuth interaction, generate and store an access token/secret in your database.
2. Generating the special URL
   You will then use this access token/secret to generate an authenticated OAuth call to /session/from_oauth
3. Using the special URL in a link
   Render a link in your page to this special URL, and if/when the user clicks on the link, they will be logged into Get Satisfaction if they aren't already.

Getting an access token

Nothing different here than any OAuth token exchange.

• Get a request token,
• redirect user to the authorization page,
• exchange request token for access token.

You will want to store this access token in your database, attached to the user account in your system who is currently signed in to your application. This token represents the link between the user's account on your system and on Get Satisfaction.

Generating a special URL

You create a URL signed properly with the Access Token retrieved in step 1. The URL will be to /session/from_oauth and you will want to sign it as a GET request. Since this URL will be embedded into a link, you won't be able to use the Authorization HTTP header method, so you should use the query string to supply the appropriate OAuth variables (token, nonce, signature, timestamp, signature method, consumer key, etc.).

Care should be taken to not cache this URL in your rendered HTML, since the first person to follow the link will be logged in as the attached user.

To redirect the user into a specific page in Get Satisfaction, you can supply an additional query string parameter. By specifying redirect=blah in the query string, Get Satisfaction will redirect the user on through to the URL specified in the parameter after setting all of the appropriate cookies to keep a user logged into satisfaction. Don't forget to include the redirect parameter (if used) when calculating the signature used for OAuth verification.

Please note that at present any cookies set using this method will always be session cookies; the user will be logged out of Get Satisfaction when they close their browser. Enabling persistent cookies is a possible feature, if enough people want it.

An alternative, better method

The method described above is less than ideal since it can interfere with caching strategies, but there is a slightly more intensive procedure. The "embed a URL" method is nice because it requires almost no effort above the initial effort to support being an OAuth consumer in your system.

The alternative is to extend your application to act as a gateway for Get Satisfaction. You will create action on your site that will redirect the user through to the special URL described above. Let's use a real world example: iwantsandy.com simply has the "community" link in their application point to their Get Satisfaction community, like this:

If they wanted their users to be automatically logged into their Get Satisfaction accounts when they clicked that link they could

1. switch that link to http://iwantsandy.com/community
2. if the currently logged user has an access token http://iwantsandy.com/community would form the special URL using the token and redirect the browser to /session/from_oauth?redirect=/iwantsandy . If not, it just redirects them into /iwantsandy.

As you can see, this method requires some implementation work over OAuth support. That said, compared to actually supporting OAuth the effort is trivial to implement the redirection gateway. In exchange, you don't actually expose any user specific information in your rendered HTML and can feel more safe in the notion that you aren't compromising your customers trust with allowing you access to their data on Get Satisfaction.