blocks|key|1196740|text|我假设你说的是典型的“服务提供商”、“消费者”和“用户”类型的设置。如果您的消费者(客户端)拒绝进行任何更改，我不知道您是否能够实现三条腿的oAuth。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1196741|会话和cookie可以用来保存令牌，但问题是需要保存它们的是您的消费者(您的客户端)，而不是您。对API的调用发生在后端，因此在该作用域中没有可用的实际会话或cookie。如果您只进行JavaScript调用，也许这确实可以工作，但即使这样，为了避免跨域脚本问题，通常也会通过代理进行调用。|1196742|在这两种情况下，如果令牌存储在会话或cookies中，则它们将是“临时”密钥，当会话或cookies过期时，用户必须重新进行身份验证。但就oAuth规范而言，这并没有什么错--只要用户不介意重新进行身份验证。|1196743|你可以参考Sample+app+for+.NET+written+using+MVC+5+Razor+engine|offset|length|1196744|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/IntuitDeveloper/SampleApp-TimeTracking_Invoicing-DotNet.git^0|0|0|0|5|1G|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I'm assuming you're talking about the typical &quot;Service Provider,&quot; &quot;Consumer&quot; and &quot;User&quot; 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 &quot;temporary&quot; 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 <a href="https://github.com/IntuitDeveloper/SampleApp-TimeTracking_Invoicing-DotNet.git" rel="nofollow noreferrer">Sample app for .NET written using MVC 5 Razor engine</a>

blocks|key|982314|text|正如Jason提到的，如果消费者应用程序不存储身份验证所需的令牌，那么它们就不可能发出身份验证请求-它们可以以任何想要的方式存储它们，但这是等式中需要的一部分。它可以是文件系统、memcache、数据库、内存。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|982315|我看到的使用cookie存储这些信息的唯一方法是，消费者应用程序将这些令牌凭据设置为用户浏览器中的cookie，并且用户在每次请求时将它们发送回消费者--然而，这看起来很荒谬，因为首先，消费者应用程序将再次需要对其代码进行更改以处理此问题，其次，令牌和令牌密钥将冗余地在网络和用户浏览器中飞行，如果用户自己决定进行黑客攻击，这可能是一个安全漏洞。|982316|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1196850|text|我在实现3条腿的oauth时也遇到了同样的问题。我在Google+App+Engine上线了我的应用程序，并使用谷歌DataStore来存储访问令牌。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1196851|然而，配额是指用于存储数据和抛出查询的here！这是使用Google+App+Engine时的唯一限制！|1196852|entityMap|0|LINK|mutability|MUTABLE|url|https://appengine.google.com/|1|http://code.google.com/appengine/docs/quotas.html^0|Q|H|0|0|J|4|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

I had the same problem when I implemented 3-legged oauth. I took my application online on <a href="https://appengine.google.com/" rel="nofollow">Google App Engine</a> &amp; used Google DataStore for storing Access Tokens.

However, the quota is mentions <a href="http://code.google.com/appengine/docs/quotas.html" rel="nofollow">here</a> for storing data &amp; throwing queries ! It is the only limitation while using Google App Engine !

blocks|key|1196883|text|关于1)将访问令牌和密钥保存在cookie中|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1196884|想想你的客户在网吧里，如果他不清理cookie，而下一个人复制了这些信息，会发生什么？|1196885|我会选择DB或PHP会话|1196886|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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

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.

OAuth: Storing Access Token and Secret

身份验证

文件系统

数据库

OAuth

我们有许多客户使用我们的API来支持他们的网站。我在工作中开始了关于使用OAuth进行身份验证API调用的对话。我们将会有两条腿和三条腿的流。对于三条腿的流，我们仍然没有就如何存储访问令牌和密钥达成共识。解决此问题的常见方法是让客户端将访问令牌和密码存储在自己的数据库中，但这是不可能的，因为客户端不想处理代码更改和实现...

问OAuth:存储访问令牌和密钥
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OAuth:存储访问令牌和密钥EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OAuth:存储访问令牌和密钥
EN