blocks|key|3051073|text|REST哲学的很大一部分是在设计API时尽可能多地利用HTTP协议的标准特性。将这一理念应用于身份验证，客户机和服务器将利用API中的标准HTTP身份验证功能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3051074|登录屏幕对于人类用户用例非常有用:访问登录屏幕，提供用户/密码，设置cookie，客户端在将来的所有请求中提供该cookie。不能期望使用web浏览器的用户在每个单独的HTTP请求中都提供用户id和密码。|3051075|但是对于REST+API来说，登录屏幕和会话cookie并不是绝对必要的，因为每个请求都可以包括凭证，而不会影响人类用户；如果客户端在任何时候都不合作，就会给出一个401+"unauthorized“响应。RFC+2617描述了超文本传输协议中的身份验证支持。|offset|length|style|CODE|3051076|TLS+(HTTPS)也是一种选择，它允许在每个请求中通过验证另一方的公钥来进行客户端到服务器的身份验证(反之亦然)。此外，这还可以确保通道的安全，从而获得奖励。当然，要做到这一点，在通信之前进行密钥对交换是必要的。(请注意，这具体是关于使用TLS来识别/验证用户。使用TLS+/+Diffie-Hellman保护通道始终是一个好主意，即使您不能通过用户的公钥来标识用户。)|3051077|例如:假设OAuth令牌是您的完整登录凭据。一旦客户端获得了HTTP令牌，它就可以作为每个请求的标准OAuth身份验证中的用户id来提供。服务器可以在第一次使用时验证令牌，并缓存带有生存时间的检查结果，该生存时间随每次请求而更新。任何需要身份验证的请求都会返回401+(如果未提供)。|3051078|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc2617^0|0|0|2A|3|2V|8|0|0|0|3M|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@$F|Y|G|Z|H|I]]|9|@$F|10|G|11|1|12]]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|14|8|@$F|15|G|16|H|I]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

A big part of the REST philosophy is to exploit as many standard features of the HTTP protocol as possible when designing your API. Applying that philosophy to authentication, client and server would utilize standard HTTP authentication features in the API.
Login screens are great for human user use cases: visit a login screen, provide user/password, set a cookie, client provides that cookie in all future requests. Humans using web browsers can't be expected to provide a user id and password with each individual HTTP request.
But for a REST API, a login screen and session cookies are not strictly necessary, since each request can include credentials without impacting a human user; and if the client does not cooperate at any time, a <code>401</code> &quot;unauthorized&quot; response can be given. <a href="https://www.rfc-editor.org/rfc/rfc2617" rel="nofollow noreferrer">RFC 2617</a> describes authentication support in HTTP.
TLS (HTTPS) would also be an option, and would allow authentication of the client to the server (and vice versa) in every request by verifying the public key of the other party. Additionally this secures the channel for a bonus. Of course, a keypair exchange prior to communication is necessary to do this. (Note, this is specifically about identifying/authenticating the user with TLS. Securing the channel by using TLS / Diffie-Hellman is always a good idea, even if you don't identify the user by its public key.)
An example: suppose that an OAuth token is your complete login credentials. Once the client has the OAuth token, it could be provided as the user id in standard HTTP authentication with each request. The server could verify the token on first use and cache the result of the check with a time-to-live that gets renewed with each request. Any request requiring authentication returns <code>401</code> if not provided.

blocks|key|3051136|text|实现安全性所必需的组件不是每个请求的DR登录，而是身份验证。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3051137|要回答你关于登录的问题很难不从总体上讲安全性。对于某些身份验证方案，没有传统的登录。|3051138|REST没有规定任何安全规则，但实际上最常见的实现是带3向身份验证的OAuth+(正如您在问题中提到的)。没有登录本身，至少每个API请求都没有登录。对于3-way+auth，您只需使用令牌。|3051139|3051140|用户批准应用编程接口客户端，并授予以长期令牌的形式进行请求的权限。|ordered-list-item|3051141|+API客户端通过使用长期令牌来获取短期令牌。|3051142|Api客户端随每个请求一起发送短期令牌。|3051143|3051144|此方案为用户提供了随时撤销访问权限的选项。实际上，我见过的所有公开可用的RESTful+API都使用OAuth来实现这一点。|3051145|我只是不认为你应该把你的问题(和问题)框定在登录上，而应该从总体上考虑保护API。|3051146|有关REST+API身份验证的一般信息，您可以查看以下资源：|3051147|3051148|http://www.infoq.com/news/2010/01/rest-api-authentication-schemes|unordered-list-item|3051149|REST+API+Authentication|3051150|RESTful+API+Authentication|3051151|3051152|entityMap|0|LINK|mutability|MUTABLE|url|1|https://stackoverflow.com/questions/7999295/rest-api-authentication|2|https://stackoverflow.com/questions/7606559/restful-api-authentication^0|2|S|0|0|16|0|0|2O|0|0|0|X|0|0|N|0|0|K|0|0|0|1Q|0|0|15|0|0|U|0|0|0|1T|0|1T|0|0|0|N|0|N|1|0|0|Q|0|Q|2|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1O|8|@$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1S|8|@$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|N|3|O|5|M|7|1V|8|@$9|1W|A|1X|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|M|7|1Y|8|@$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|21|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|22|8|@$9|23|A|24|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|25|8|@$9|26|A|27|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|28|8|@$9|29|A|2A|B|C]]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|2B|8|@]|D|@]|E|$]]|$1|Z|3|10|5|11|7|2C|8|@$9|2D|A|2E|B|C]]|D|@$9|2F|A|2G|1|2H]]|E|$]]|$1|12|3|13|5|11|7|2I|8|@$9|2J|A|2K|B|C]]|D|@$9|2L|A|2M|1|2N]]|E|$]]|$1|14|3|15|5|11|7|2O|8|@$9|2P|A|2Q|B|C]]|D|@$9|2R|A|2S|1|2T]]|E|$]]|$1|16|3|-4|5|6|7|2U|8|@]|D|@]|E|$]]|$1|17|3|-4|5|6|7|2V|8|@]|D|@]|E|$]]]|18|$19|$5|1A|1B|1C|E|$1D|10]]|1E|$5|1A|1B|1C|E|$1D|1F]]|1G|$5|1A|1B|1C|E|$1D|1H]]]]

TL;DR Login for each request is not a required component to implement API security, authentication is.

It is hard to answer your question about login without talking about security in general. With some authentication schemes, there's no traditional login.

REST does not dictate any security rules, but the most common implementation in practice is OAuth with 3-way authentication (as you've mentioned in your question). There is no log-in per se, at least not with each API request. With 3-way auth, you just use tokens.

<ol>
<li>User approves API client and grants permission to make requests in the form of a long-lived token</li>
<li>Api client obtains a short-lived token by using the long-lived one.</li>
<li>Api client sends the short-lived token with each request.</li>
</ol>

This scheme gives the user the option to revoke access at any time. Practially all publicly available RESTful APIs I've seen use OAuth to implement this.

I just don't think you should frame your problem (and question) in terms of login, but rather think about securing the API in general.

For further info on authentication of REST APIs in general, you can look at the following resources:

<ul>
<li><a href="http://www.infoq.com/news/2010/01/rest-api-authentication-schemes" rel="noreferrer">http://www.infoq.com/news/2010/01/rest-api-authentication-schemes</a></li>
<li><a href="https://stackoverflow.com/questions/7999295/rest-api-authentication">REST API Authentication</a></li>
<li><a href="https://stackoverflow.com/questions/7606559/restful-api-authentication">RESTful API Authentication</a></li>
</ul>

blocks|key|204170|text|Principled+Design+of+the+Modern+Web+Architecture+by+Roy+T.+Fielding+and+Richard+N.+Taylor，即来自所有REST术语的工作序列，包含客户端-服务器交互的定义：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|204171|204172|所有的REST交互都是无状态。也就是说，每个请求都包含连接器理解该请求所需的所有信息，独立于它之前的任何请求。|blockquote|style|BOLD|204173|204174|204175|此限制实现了四个功能，在此特定情况下，第一个和第三个功能非常重要：|204176|204177|+for+:+it+消除了连接器在请求之间保留应用程序状态的任何需要，从而减少了物理资源的消耗并提高了scalability;|unordered-list-item|204178|3rd:它允许中介在中查看和理解请求，这在服务动态重新排列时可能是必需的；|204179|204180|现在让我们回到你的安全案例。每个请求都应该包含所有必需的信息，授权/身份验证也不例外。如何做到这一点？从字面上看，每个请求都会通过网络发送所有需要的信息。|204181|如何理解这一点的一个例子是+or+。实际上，这意味着向每个请求添加当前消息的哈希码。由加密散列函数与秘密加密密钥组合计算的散列码。加密散列函数可以是预定义的，也可以是按需编码REST概念的一部分(例如JavaScript)。服务器应将秘密密钥作为资源提供给客户端，客户端使用该密钥计算每个请求的哈希码。|204182|HMAC实现有很多示例，但我希望您关注以下三个示例：|204183|204184|Authenticating+REST+Requests+for+Amazon+Simple+Storage+Service+(Amazon+S3)|204185|Answer+by+Mauriceless+on+quiestion:+"How+to+implement+HMAC+Authentication+in+a+RESTful+WCF+API"|204186|crypto-js:+JavaScript+implementations+of+standard+and+secure+cryptographic+algorithms|204187|204188|它在实践中是如何工作的|204189|如果客户端知道密钥，那么它就可以使用资源进行操作了。否则，他将被临时重定向(状态代码307临时重定向)以授权并获取密钥，然后重定向回原始资源。在这种情况下，不需要事先知道(即在某个地方硬编码)授权客户端的URL是什么，并且可以随时间调整此模式。|204190|希望这能帮助你找到合适的解决方案！|204191|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf|1|http://en.wikipedia.org/wiki/Hash-based_message_authentication_code|2|http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html|3|https://stackoverflow.com/a/8366526/443366|4|http://code.google.com/p/crypto-js/#Progressive_HMAC_Hashing^0|0|2H|0|0|0|B|3|M|W|0|0|0|0|0|A|O|0|0|0|0|D|4|1|0|0|4|0|0|0|22|2|0|0|2N|3|0|0|2D|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1U|8|@]|9|@$A|1V|B|1W|1|1X]]|C|$]]|$1|D|3|-4|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1Z|8|@$A|20|B|21|H|I]|$A|22|B|23|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|25|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|26|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|27|8|@]|9|@]|C|$]]|$1|O|3|P|5|Q|7|28|8|@$A|29|B|2A|H|I]]|9|@]|C|$]]|$1|R|3|S|5|Q|7|2B|8|@]|9|@]|C|$]]|$1|T|3|-4|5|6|7|2C|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|2D|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|2E|8|@]|9|@$A|2F|B|2G|1|2H]]|C|$]]|$1|Y|3|Z|5|6|7|2I|8|@$A|2J|B|2K|H|I]]|9|@]|C|$]]|$1|10|3|-4|5|6|7|2L|8|@]|9|@]|C|$]]|$1|11|3|12|5|Q|7|2M|8|@]|9|@$A|2N|B|2O|1|2P]]|C|$]]|$1|13|3|14|5|Q|7|2Q|8|@]|9|@$A|2R|B|2S|1|2T]]|C|$]]|$1|15|3|16|5|Q|7|2U|8|@]|9|@$A|2V|B|2W|1|2X]]|C|$]]|$1|17|3|-4|5|6|7|2Y|8|@]|9|@]|C|$]]|$1|18|3|19|5|6|7|2Z|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|6|7|30|8|@]|9|@]|C|$]]|$1|1C|3|1D|5|6|7|31|8|@]|9|@]|C|$]]|$1|1E|3|-4|5|6|7|32|8|@]|9|@]|C|$]]]|1F|$1G|$5|1H|1I|1J|C|$1K|1L]]|1M|$5|1H|1I|1J|C|$1K|1N]]|1O|$5|1H|1I|1J|C|$1K|1P]]|1Q|$5|1H|1I|1J|C|$1K|1R]]|1S|$5|1H|1I|1J|C|$1K|1T]]]]

<a href="http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf" rel="noreferrer">Principled Design of the Modern Web Architecture by Roy T. Fielding and Richard N. Taylor</a>, i.e. sequence of works from all REST terminology came from, contains definition of client-server interaction:

<blockquote>
 All REST interactions are stateless. That is, each request contains
 all of the information necessary for a connector to understand the
 request, independent of any requests that may have preceded it. 
</blockquote>

This restriction accomplishes four functions, 1st and 3rd are important in this particular case:

<ul>
<li>1st: it removes any need for the connectors to retain application state
 between requests, thus reducing consumption of physical resources
 and improving scalability;</li>
<li>3rd: it allows an intermediary to view and understand a request in isolation,
 which may be necessary when services are dynamically rearranged;</li>
</ul>

And now lets go back to your security case. Every single request should contains all required information, and authorization/authentication is not an exception. How to achieve this? Literally send all required information over wires with every request.

One of examples how to archeive this is <a href="http://en.wikipedia.org/wiki/Hash-based_message_authentication_code" rel="noreferrer">hash-based message authentication code or HMAC</a>. In practice this means adding a hash code of current message to every request. Hash code calculated by cryptographic hash function in combination with a secret cryptographic key. Cryptographic hash function is either predefined or part of code-on-demand REST conception (for example JavaScript). Secret cryptographic key should be provided by server to client as resource, and client uses it to calculate hash code for every request.

There are a lot of examples of HMAC implementations, but I'd like you to pay attention to the following three:

<ul>
<li><a href="http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html" rel="noreferrer">Authenticating REST Requests for Amazon Simple Storage Service (Amazon S3)</a></li>
<li><a href="https://stackoverflow.com/a/8366526/443366">Answer by Mauriceless on quiestion: "How to implement HMAC Authentication in a RESTful WCF API"</a></li>
<li><a href="http://code.google.com/p/crypto-js/#Progressive_HMAC_Hashing" rel="noreferrer">crypto-js: JavaScript implementations of standard and secure cryptographic algorithms</a></li>
</ul>

<h2>How it works in practice</h2>

If client knows the secret key, then it's ready to operate with resources. Otherwise he will be temporarily redirected (status code 307 Temporary Redirect) to authorize and to get secret key, and then redirected back to the original resource. In this case there is no need to know beforehand (i.e. hardcode somewhere) what the URL to authorize the client is, and it possible to adjust this schema with time.

Hope this will helps you to find the proper solution!

I am creating a REST api, closely following apigee suggestions, using nouns not verbs, api version baked into the url, two api paths per collection, GET POST PUT DELETE usage, etc.

I am working on the login system, but unsure of the proper REST way to login users. I am not working on security at this point, just the login pattern or flow. (Later we will be adding 2 step oAuth, with an HMAC, etc)

Possible Options

<ul>
<li>A POST to something like <code>https://api...com/v1/login.json</code> </li>
<li>A PUT to something like <code>https://api...com/v1/users.json</code></li>
<li>Something I have not though of...</li>
</ul>

What is the proper REST style for logging in users?

REST API Login Pattern

身份验证

RESTful API

服务器

OAuth

我正在创建一个REST api，密切遵循apigee的建议，使用名词而不是动词，url中烘焙的api版本，每个集合两个api路径，GET POST PUT DELETE用法等。我在登录系统上工作，但不确定正确的REST方式登录用户。在这一点上，我不是在做安全性方面的工作，只是在研究登录模式或流程。(稍后我们将添加具有H...

问REST API登录模式
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST API登录模式EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST API登录模式
EN