如何使用 ServiceStack.Net 实现客户端身份验证
我正在使用 servicestack.net 库开发 Web 服务。
在我的场景中，将从 WPF 应用程序调用 Web 服务。我需要能够验证只有经过批准的客户端应用程序才能调用我的服务。
这与在客户端应用程序中硬编码“用户名”和“密码”一样简单吗？这显然不是正确的方法。有更好的办法吗？
编辑 此外，在客户端，用户自己将能够使用用户名/密码登录并向服务发起请求（不确定这是否会产生任何影响，所以我想我会提到它），
I am developing web services using the servicestack.net library.
In my scenario, the web services will be called from a WPF application. I need the ability to authenticate that only an approved client app is calling my service.
Is this as simple as hardcoding a "username" and "password" in the client application? This certainly does not seem like the proper approach. Is there a better way?
EDIT
In addition, on the client end, Users themselves will be able to login with a username/password and initiate requests to the service(not sure if this effects anything, so I thought I would mention it),
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有关 ServiceStack 中身份验证的更多背景信息请参阅此问题< /a>.
通常，您会验证用户而不是客户端，而您似乎还在这样做。但是，如果您尝试锁定服务，以便只能通过一组特定的客户端访问它们，您应该考虑在客户端和服务器中使用一些 PKI。
基本上是这样的：客户端在登录时发送一个附加令牌，其中包含用户的加密版本：密码以及嵌入在应用程序中的私钥。服务器拥有客户端公钥，因此将在登录时执行额外的验证步骤以解密 user:pass 令牌并将其与经过验证的用户凭据进行比较。
如果 PKI 解决方案太繁重，则不使用加密的替代策略可能是为客户端提供一个秘密 Guid，当他们登录时，它将发送 Guid 的 MD5 哈希版本和当前时间，以及未哈希版本的 Guid。时间。如果时间在指定阈值内并且 MD5 哈希有效，则他们使用经过身份验证的客户端。
For more background information about Authentication in ServiceStack see this question.
Normally you would authenticate users not clients which you seem to be doing in addition. But if you're trying to lock down services so their only accessible via a specific set of clients you should look into employing some PKI into your client and server.
Basically something along the lines of: the client sends an additional token at login with an encrypted version of the user:password together with a private key embedded in the app. The server has the client public key and so would do un extra validation step on Login to unencrypt the user:pass token and compare it with the validated user credentials.
If a PKI solution is too heavy, an alternate strategy without using encryption could be for clients to ship with a secret Guid which when they login which will send an MD5 hash version of the Guid and the current time, as well as the unhashed version of the time. If the time is within a specified threshold and the MD5 hash is valid then their using an authenticated client.