公共原生移动应用程序中的 WSO2 Api Manager OAuth2 DCR 安全性 [英] WSO2 Api Manager OAuth2 DCR security in public native mobile app
问题描述
我正在为 iOS 和 Android 的公共原生移动应用程序设计安全性，该应用程序使用公开可用的 API，使用 WSO2 Api Manager (APIM).
I am designing security in a public native mobile application for iOS and Android which is using publicly available API using WSO2 Api Manager (APIM).
因此，我了解与此设置相关的安全问题，并且我想将 OAuth2 应用于本机应用程序(根据 RFC 8252).
As such I understand the security issues that are related to this setup and I would like to apply OAuth2 for native apps (according RFC 8252).
我明白这样的应用程序应该做的第一件事是通过Store API 以便为每个应用程序接收唯一的使用者密钥/秘密，即动态客户端注册 (DCR).
I understand that the first thing that such application should do is to register with WSO2 APIM server through the interface described in Store API in order to receive unique consumer key/secret for every application, which is Dynamic Client Registration (DCR).
以下是为获取密钥而应发送的请求示例:
The following is sample of request that should be sent in order to get keys:
curl -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -d @payload.json https://localhost:9443/client-registration/v0.11/register
要执行此类请求，应使用 TLS 1.2 进行保护，并且使用 WSO2 APIM 的用户名/密码进行基本授权(在本例中为 Base64 编码的 admin:admin)
To do such request, it should be secured using TLS 1.2 and there is a Basic Authorization using username/password of WSO2 APIM (which in this case is Base64 encoded admin:admin)
我知道它至少应该受到基本授权的保护，以提供一些针对 DoS 攻击的安全性，但另一方面，这意味着应用程序应该与 username:password 一起分发，以便能够做 DCR.
I understand that it should be protected at least by Basic Authorization to provide some security against DoS attacks, but on the other hand that means that the application should be distributed with username:password in order to be able to do DCR.
如果将其与此信息一起分发，那么每个人都可以获取该信息并请求例如恶意应用程序注册.
And if it will be distributed with this information then everyone can get the information and request for example malicious application registration.
如何处理本机移动应用程序以安全地在 WSO2 APIM 中注册?我认为我对其工作原理的理解中缺少一些东西.
How is the native mobile application handled in order to register in WSO2 APIM securely? I think that there is something missing in my understanding of how it works.
这是否意味着安装移动应用程序的用户应该在 WSO2 APIM 上拥有自己的帐户，并且应该在安装后立即提供凭据?
Does it mean that the user who installed the mobile application should have its own account on WSO2 APIM and should provide credentials right after installation?
如果用户没有 WSO2 APIM 中的凭据，但拥有通过 WSO2 APIM 中的 API 访问的后端服务的凭据，情况会怎样?是否可以使用此类凭据通过 WSO2 APIM 的 DCR 注册应用程序?(目前后端和WSO2 APIM认证没有集成)
What about situation when the user does not have credentials in WSO2 APIM but has credentials for backend service that is accessed through API from WSO2 APIM? Can such credentials be used in order to register application through DCR of WSO2 APIM? (currently the backend and WSO2 APIM authentication has no integration)
推荐答案
您对 APIM 工作原理的理解部分正确.让我解释并纠正整个事情.
Your understanding of how APIM works is partially correct. Let me explain and correct the whole thing.
基本上，这个场景有 3 个参与方.
Basically, there are 3 parties involved in this scenario.
- API 开发者/发布者
- 应用程序开发人员(即您，我猜，在你的情况下)
- 最终用户(即您的移动用户)
如您所知，API 开发人员从发布者门户开发和发布 API.然后应用程序开发人员可以在 API Store Portal 中看到这些 API.现在，如果他们想在他们的移动应用程序中使用这些 API，他们需要订阅这些 API.为此，他们需要 API 管理器中的某些内容来表示他们的移动应用程序.为此，他们在 API Store 门户中创建一个应用程序，然后通过创建的应用程序订阅 API.
As you already know, API developers develop and publish APIs from Publisher portal. Then Application developers can see those APIs in API Store Portal. Now, if they want to use those APIs in their mobile apps, they need to subscribe to those APIs. For that, they need something in API manager to represent their mobile app. For that, they create an application in API Store portal and then subscribe to APIs through the created application.
现在应用开发者需要密钥才能通过他们的移动应用调用 API.为此，他们通过商店门户进行 DCR 调用并生成消费者密钥和消费者秘密对.使用这些，他们可以生成访问令牌.
Now App Developers need keys to invoke APIs via their mobile app. For that, they do a DCR call via Store portal and generate consumer-key and consumer-secret pair. Using those, they can generate access tokens.
生成访问令牌有几种不同的方法.我们称它们为赠款类型.例如，密码授予类型、客户端凭据授予类型、授权码授予类型等.客户端凭据授予类型只需要消费者密钥和消费者秘密对即可生成访问令牌，其中密码授予类型还需要用户名和密码到消费者密钥，消费者秘密对.因此，如果您的移动应用程序用户位于某种用户存储中，您可以使用密码授权类型，这可以帮助您识别 APIM 级别的每个用户.如果您没有这样的机制，您可以使用客户端凭据授权类型，您无法在 APIM 级别区分最终用户.这里由密码授权类型生成的令牌代表最终用户，而由客户端凭据授权类型生成的令牌代表应用程序.
There are a few different ways of generating an access token. We call them grant types. For example, password grant type, client credentials grant type, authorization code grant type etc. Client credentials grant type only needs consumer-key and consumer-secret pair to generate an access token, where password grant type needs a username and password too in addition to consumer-key, consumer-secret pair. So, if you have your mobile app users in some kind of a userstore, you can use password grant type, and that can help you identify each user in APIM level. If you don't have such a mechanism, you can use client credentials grant type, by which you can't differentiate end users at APIM level. Here a token generated by password grant type represents the end user, while a token generated by client credentials grant type represents the application.
在任何一种情况下，应用程序开发人员都必须将消费者密钥和消费者秘密对嵌入到他们的移动应用程序中，以便最终用户可以生成访问令牌来访问 API.重要的是用户不必单独调用 DCR.这是应用程序开发人员的任务.
In either case, the application developer has to embed consumer-key and consumer-secret pair into their mobile app, so that end users can generate access tokens to access the APIs. The important thing is users don't have to call DCR individually. It's a task of the application developer.
我希望这会有所帮助.
EIDT:
如果您让用户注册移动应用并将他们保存在用户商店中，您可以使用授权代码授权类型.然后您可以在您的移动应用程序中仅启用授权代码授权类型，并设置回调 URL.因此，如果有人窃取了消费者机密并在不同的应用程序中使用它，即使通过授权代码授予类型，他们也无法使用它来生成令牌，因为回调 URL 在服务器端进行了验证.
If you let users sign up for the mobile app and have them in a userstore, you can use Authorization code grant type. Then you can enable only the Authorization Code grant type in your mobile app, and set the callback URL. So if someone steals the consumer secret and use it in a different app, they can't use it to generate a token even via Authorization code grant type, because the callback URL is validated in the server side.
另一个选项是隐式授权类型，它不需要客户端机密，但它有自己的缺陷.
Another option is implicit grant type, which does not require client-secret, but it has its own flaws.
这篇关于公共原生移动应用程序中的 WSO2 Api Manager OAuth2 DCR 安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
