OAuth: Storing Access Token and Secret

Onema picture Onema · Jul 19, 2010 · Viewed 18.6k times · Source

We have a number of clients that use our API to power their websites.

I have started a conversation at work about using OAuth to make authenticated API Calls. We will have both, two and three legged flows.

For the 3-legged flow, we still have not come to a consensus on how to store the access token and secret.

The common approach to this problem would be to have the clients store the access token and secret in their own DB, but that is out of the question as the clients don't want to deal with code changes and implementation issues.

The other options we are considering:

1) Saving the access token and secret in a cookie

2) Saving them in the session.

I'm not sure whether either of these is a good idea. Does anyone have any suggestions?

Thank you.

Answer

Jason picture Jason · Aug 4, 2010

I'm assuming you're talking about the typical "Service Provider," "Consumer" and "User" type of setup. I don't know if you will be able to implement three-legged oAuth if your Consumers (client) refuse to make any changes.

The session and cookies would work for saving tokens, but the problem is that it's your Consumer (your clients) that needs to be saving them - not you. The calls to your API are happening on the back-end and so there is no real session or cookie available within that scope. If you are only making JavaScript calls, perhaps that does work but even then usually the calls are being made through a proxy in order to not have cross-domain scripting issues.

In either case, if the tokens are stored in the session or cookies, they will be "temporary" keys and the User will have to re-authenticate when the session or cookies expire. But there is nothing wrong with that as far as the oAuth spec goes - as long as the Users don't mind re-authenticating.

You can refer Sample app for .NET written using MVC 5 Razor engine