OAuth: Storing Access Token and Secret

Question

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 wi

Answer 1

I had the same problem when I implemented 3-legged oauth. I took my application online on Google App Engine & used Google DataStore for storing Access Tokens.

However, the quota is mentions here for storing data & throwing queries ! It is the only limitation while using Google App Engine !

Answer 2

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

Answer 3

about 1) Saving the access token and secret in a cookie

consider your client in an internet cafe and what happens after he doesnt clear cookies and next person copies this informations?

I'd go for DB or PHP session

Answer 4

as Jason mentioned it's not possible for the consumer application to make authenticated requests if they don't store the tokens needed for the authentication - they can store them in whatever way they want but this is a needed part of the equation. It can be a filesystem, memcache, database, memory.

The only way I see to use cookies for storing these is for the consumer application to set these token credential as a cookie in the user's browser and the user to send them back to the consumer with every request - however this seems absurd as first, the consumer application again will need to make changes in their code to handle this, and second, the token and token secret keys will redundantly fly around the net and the user's browser which can be a security hole if the user himself decide to do hacking.