客户端应用认证 [英] Client Application Authentication

问题描述

我正在开发一个分布式应用程序，使用基于ASP.net Web-API的REST服务托管在azure上作为云服务。



这些服务由各种客户端应用程序使用（例如Web应用程序（SPA），其他Web服务，移动设备上的本机应用程序）。



我们的Rest Web Service（RWS）有许多操作，一些是授权安全的，另一些是开放的，因为有些操作只允许真实用户，而有些则不允许。随着用户通过FORM身份验证进行验证，到目前为止，该系统运行良好，并且已安装SSL。



希望以上说明为我提供足够的上下文来解决问题声明现在。



问题陈述：我现在也需要识别和授权客户申请。

，不知何故，在某种程度上，Web服务将识别和授权已知的客户端应用程序，仅用于请求任何资源或授权用户。



假设：

1）Azure Web服务有一个动作URI，如https：//www.somedomain/api/somecontroller/someaction



2）移动应用程序我发布的my-mobile-app会使用此URI。我希望允许my-mobile-app通过识别/授权来使用URI。

我知道my-mobile-app，我喜欢它。我首先识别/授权此客户端应用程序，然后允许它尝试最终用户身份验证。



3）另一个移动应用程序blah-mobile-app，已发布由其他人知道这个URI并尝试使用此URI。我不想让它使用这个URI。我想关上它的脸。纳达。压缩。我不会接受这个客户申请来提出任何资源请求。





想到一个快速潜在的解决方案是：到为客户端应用程序提供预定义的KEY，然后使用HTTP处理程序拦截传入的调用，以确定是否存在此KEY以识别和授权客户端。但我真的很感激为这个问题提供一种更易于管理的方法，因为我可能需要将此解决方案扩展到所有可能的客户端。谁知道其他网络服务项目也可能需要类似的解决方案。



如果需要其他信息或任何问题部分不清楚，请告诉我。

Hi,

I am working on a distributed application with ASP.net Web-API based REST services hosted on azure as Cloud Services.

These services are consumed by a variety of client applications ( ex. Web applications (SPA), Other web services, native application on mobile devices).

Our Rest Web Service (RWS) has a number of actions, some are secure with Authorization and other are open, as in some are only allowed for authentic user while others are not. As users are verified with FORM authentication, this system works well so far with SSL in place.

Hopefully description above sets the required context enough for me to come to the problem statement now.

Problem Statement: I am now in need to identify and authorize client application as well.
i.e. Somehow, in some way, web services would identify and authorize known client applications only to request for any resource or to authorize users.

Assume:
1) Azure web service has a action URI like "https://www.somedomain/api/somecontroller/someaction"

2) a mobile app "my-mobile-app", published by me, consumes this URI. i want to allow "my-mobile-app" to consume URI by identifying/authorizing it.
I know "my-mobile-app", i love it. I identify/authorize this client application first and then allow it to attempt the end-user authentication.

3) another mobile app "blah-mobile-app", published by someone else, somehow knows this URI and attempts to consume this URI. I DO NOT want to allow it to consume this URI. i want to just close door on it's face. Nada. zip. i won't entertain this client application to make any request for resources.


A quick potential solution which comes to mind is: to give a predefined KEY to client application and then to use a HTTP Handler to intercept incoming calls for presence of this KEY to identify and authorize client. but would really appreciate a better more manageable approach for this problem as i may have to extend this solution to all possible clients. and who knows may need similar solutions on other web service projects as well.

Let me know if additional information is needed or any section of question is not clear.

推荐答案

探索了OAuth 2.0并找到了我的孤独感。



我的特殊问题，Client Credential Grant是然而，答案意识到，通过所有支持的选项，隐式授权可以解决我在验证用户以及移动设备上的应用程序时遇到的其他问题。感谢您的推荐。



对于在这里寻找答案的人，我的建议是仔细查看OAuth2.0或其他类似选项。

Explored OAuth 2.0 and found my solitude in there.

for my particular problem, Client Credential Grant was the Answer, however realized that with all the supported options, implicit grant would solve other problems i was having with authenticating users and thus applications on mobile devices as well. thanks for recommendations.

For anyone looking for answer here, my recommendation is to have a hard look at OAuth2.0 or other similar options.

您好Omni，



有几种方法可以解决这个问题：



1在你的脑海中，它被称为基于令牌的身份验证，提供一些识别用户的关键，在做同样的事情时你应该记住的几件事情

a。它不应该是静态令牌

b。做一些IP级别检查

c。是否存在任何类型的会话共享？



2.基于会话的检查，因为您正在构建一个Web应用程序，无论设备将会打到您的应用程序，它将创建一个会话，所以你可以在会议中保存所需的信息

a。会话驻留在服务器端，因此它会增加服务器端的负载

b。会话缓和非常简单，所以要小心



3.基于OpenAuth或基于Cookie，创建集中的身份验证服务，从所有应用程序模式中使用它，一旦通过身份验证，您将提供某种AuthToken，每次都会传输

a。当你使用cookie时，你应该使用安全的cookie

b。不要使用纯文本使用加密文本



现在选择是你的，还有很多其他方面它取决于替换情况

Hi Omni,

There are several ways to solve this problem:

1. Which is in your mind its called token based authentication, provide some key to identify user, few things you should keep in mind while doing the same
a. Its should not be a static token
b. Do some IP level check
c. Is there any kind of session sharing?

2. Session based check, as you are building a web application what ever device is going to hit your application it will create a session so you could hold your required information in session
a. Session resides at server end so it will increase load a server end
b. Session tempering is quite easy so be CAREFUL

3. OpenAuth based or Cookie based, create you authentication service centralized, consume it from all modes of application, once authenticated you will porvide some kind of AuthToken, which will be transmitted every time
a. As you using cookie you should use secure cookie
b. Don't use plain text use encrypted text

Now choice is yours, there are many other aspects it vary situation to substitution

这篇关于客户端应用认证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！