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.
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
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.
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 !
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
来源：https://stackoverflow.com/questions/3284260/oauth-storing-access-token-and-secret