C# REST 服务认证

REST service authentication

提问by jgauffin

What are the best practice for implementing authentication for REST apis?

为 REST api 实现身份验证的最佳实践是什么？

Using BASIC auth + SSL or something like http://tools.ietf.org/html/draft-hammer-http-token-auth-01?

使用 BASIC auth + SSL 或类似http://tools.ietf.org/html/draft-hammer-http-token-auth-01 的东西？

Are there any existing solutions available (for .NET / WebApi)?

是否有可用的现有解决方案（适用于 .NET / WebApi）？

采纳答案by Jos Vinke

The answer on this depends on the audience for your Web API and what you want to authenticate exactly.

答案取决于您的 Web API 的受众以及您想要准确验证的内容。

• Do you want to authenticate a client application that uses your Api?
• Do you want to authenticate a user from your application to retrieve their data within a client application (using your Api)?
• Or do you want to authenticate both the client application and the user using the client application.

• 您想对使用您的 Api 的客户端应用程序进行身份验证吗？
• 您想从您的应用程序中对用户进行身份验证以在客户端应用程序中检索他们的数据（使用您的 Api）吗？
• 或者您想同时验证客户端应用程序和使用客户端应用程序的用户。

Depending on what you want to authenticate you have multiple options. But always keep in mind that it is better to go with a solid solution where many client libraries are available than reinvent you own. Never do a little off this, but in your own way, chose one way of authentication, stick to it and don't break the client libraries.

根据您要验证的内容，您有多种选择。但请始终牢记，与其重新发明您自己的库，还不如选择一个有许多客户端库可用的可靠解决方案。永远不要做任何事，而是以您自己的方式，选择一种身份验证方式，坚持下去，不要破坏客户端库。

Basic authentication:Is very easy to implement, but you authenticate a client app with it, not a user. This kind of authentication is nice when business trust relation needed and authentication and safety is not your very first concern. But there is no way to track a call in your API back to a certain user, just a client application. Of course you could save your user's username and password in a client application but this is a bad practice in more then a single way.

基本身份验证：非常容易实现，但您使用它来验证客户端应用程序，而不是用户。当需要业务信任关系并且身份验证和安全不是您最关心的问题时，这种身份验证很好。但是没有办法在您的 API 中跟踪对某个用户的调用，只能跟踪客户端应用程序。当然，您可以将用户的用户名和密码保存在客户端应用程序中，但这是一种不好的做法。

Token based authentication:Their are many ways of token authentication but the one i'm talking about here is a single token for a user which the user copies to the client application to get access to your Api. This way you can authenticate a user (who made this call in my Api?) And it is fairly easy to make and use. The withdrawal is that it is not the most secure way, requires user interaction and that a user possibly uses his Api token in more then one application. You could extend this way of authentication with basic authentication to authenticate a client. So a clientid + clientsecret + token to identify the user. But I think if you want to accomplish this it would be better to take a look at Oauth2.

基于令牌的身份验证：他们有多种令牌身份验证方式，但我在这里谈论的是用户的单个令牌，用户将其复制到客户端应用程序以访问您的 Api。通过这种方式，您可以对用户进行身份验证（谁在我的 Api 中进行了此调用？）而且制作和使用相当容易。撤回是它不是最安全的方式，需要用户交互，并且用户可能在多个应用程序中使用他的 Api 令牌。您可以使用基本身份验证扩展这种身份验证方式来对客户端进行身份验证。所以一个clientid + clientsecret + token 来识别用户。但我认为如果你想完成这个，最好看看 Oauth2。

OAuth2:If you want to have full access over your authentication you can go this way. It is possibly the most future proof way to go, but also requires the most work (at least at the identity provider/resource provider side. The client application has a fairly easy time implementing this with a lot available client libraries. If you go with this way of authentication (also token based) you can authenticate the client and the user, without the need to share your users username and password.

OAuth2：如果你想对你的身份验证拥有完全访问权限，你可以这样做。这可能是最适合未来证明的方式，但也需要最多的工作（至少在身份提供者/资源提供者方面。客户端应用程序可以通过大量可用的客户端库轻松实现这一点。如果你使用这种身份验证方式（也是基于令牌的）您可以对客户端和用户进行身份验证，而无需共享您的用户用户名和密码。

My recommendation:would be to go with Basic Authentication if this fits your case, it is easy and together with HTTPS is fairly safe. If it doesn't fit I would go with Oauth2 because it is the most solid and used standard (Instagram/Google/Facebook), gives you a lot off freedom and with a growing ecosystemgets easier and easier to implement. After all for someone implementing your API it is way more interesting to learn something about Oauth 2.0, then learn about the jgauffinway of doing things.

我的建议：如果适合您的情况，请使用基本身份验证，这很容易，并且与 HTTPS 一起使用相当安全。如果它不适合我会选择 Oauth2，因为它是最可靠和最常用的标准（Instagram/ Google/ Facebook），给你很多自由，并且随着生态系统的不断发展，它变得越来越容易实现。毕竟对于实现你的 API 的人来说，学习一些关于 的东西Oauth 2.0，然后学习jgauffin做事的方式更有趣。

Reference:I would also like to invite you to have a look at Apigee's website. Api's are their business and they have quite some interesting reads. One of them is is a free ebook - Oauth the big picturewhich also has a interesting paragraph where they ask if you really need Oauth. (From page 16 - Is OAuth all you need for API security?)

参考：我也想邀请你看看 Apigee 的网站。Api 是他们的业务，他们有一些有趣的读物。其中之一是免费电子书 - Oauth the big picture其中还有一个有趣的段落，他们询问您是否真的需要 Oauth。（从第 16 页开始 - OAuth 是 API 安全所需的全部吗？）

For server-to-server APIs- APIs designed to be used only by a small number of servers – OAuth is overkill. Having a separate set of authentication credentials for each app is a nice feature of OAuth, but for server-to-server use, the need to log in securely using a browser, or to implement other steps in the OAuth “dance,” gets in the way. Instead, using a simple security standard like HTTP Basic authentication and assigning a unique password to each app is sufficient. Two-way SSL is another good, albeit cumbersome approach that has the advantage of stronger, more traceable authentication. However, think ahead! Are those APIs really only going to be used by servers forever?

对于服务器到服务器 API- 旨在仅由少数服务器使用的 API - OAuth 太过分了。为每个应用程序拥有一组单独的身份验证凭据是 OAuth 的一个很好的功能，但对于服务器到服务器的使用，需要使用浏览器安全登录，或者在 OAuth“舞蹈”中实现其他步骤，道路。相反，使用简单的安全标准（如 HTTP 基本身份验证）并为每个应用程序分配一个唯一的密码就足够了。双向 SSL 是另一种很好的方法，尽管很麻烦，但它具有更强、更可追踪的身份验证的优点。但是，请提前考虑！这些 API 真的只会永远被服务器使用吗？

Exisisting Solutions:Whatever way you go leastprivilege - Dominick Baier and his nuget packages can give you a nice headstart. Implementing basic authenticationusing his Identitymodelis really easy. Also if you want a ready-to-go identityserverto provide you with tokens look at his identity server which does all you can think off. However if you decide to go for Oauth2I would also have a look at DotnetOpenAuthsince it is (imho) a bit more configurable and easier to tweak to your own like, but it also takes more work.

现有解决方案：无论您采用哪种方式，最少特权 - Dominick Baier 和他的 nuget 软件包都可以为您提供良好的开端。basic authentication使用他的Identitymodel实现真的很容易。此外，如果你想有一个现成的去identityserver为您提供的令牌看看它做了所有你能想到他的身份服务器。但是，如果您决定选择，Oauth2我也会看看DotnetOpenAuth，因为它（恕我直言）更具可配置性并且更容易根据您自己的喜好进行调整，但它也需要更多的工作。

回答by dutzu

You should look into Security Token Serviceor STS.

你应该看看Security Token Service或STS。

Check out these links for more information:

查看这些链接以获取更多信息：

Off-the-shelf Security Token Service (STS) that uses ASP.NET membership provider?

使用 ASP.NET 成员资格提供程序的现成安全令牌服务 (STS)？

http://msdn.microsoft.com/en-us/library/ee517259.aspx

http://msdn.microsoft.com/en-us/library/ee517259.aspx

回答by leastprivilege

You could have a look here, IdentityModel has Web API support:

你可以看看这里，IdentityModel 有 Web API 支持：

http://thinktecture.github.com/Thinktecture.IdentityModel.45/

http://thinktecture.github.com/Thinktecture.IdentityModel.45/