公共本地移动应用程序中的WSO2 Api Manager OAuth2 DCR安全性

Question

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).

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 ).

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

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 )

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.

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.

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?

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)

Answer 1

Your understanding of how APIM works is partially correct. Let me explain and correct the whole thing.

Basically, there are 3 parties involved in this scenario.

1. API developers/publishers
2. Application developers (ie You, I guess, in your case)
3. End users (ie mobile users in your case)

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.

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.

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.

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.

I hope this helps.

EIDT :

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.