Securing Mobile APIs using the OAuth2 Resource Owner Password Flow
For mobile applications (on smartphones/tablets) a typical use case is that you let a user log in to your service, or create some kind of unique identifier for the user's device, which is considered the identity of the user, and that you then allow access only in the context of this user to your backend API.
In order to prevent fraud or excessive usage of your API, it's also typical to apply rate limiting by number of calls per authorized user and application.
In this use case we assume that your user base is already contained in some external system (LDAP/SAML/other IdP), and you want to leverage this user base in a new mobile application, which is to make use of your mobile backend API. The only constraint is that your Identity Provider needs to provide a headless means (e.g. an API) to verify an end user's credentials, e.g. username and password.
For development time, the following workflow is typical:
For the OAuth2.0 Resource Owner Password Grant, it is not necessary and advised against to also incorporate the client secret into the mobile app; in case the API also supports the client credentials flow, this would enable attackers to reverse engineer the app and extract the credentials. The client ID on the other hand is only helpful in combination with an end user identity, which the end user will also try to protect.
At runtime, the authentication and authorization of the API usage for the end user inside the mobile app will work as follows. When the end user opens the application for the first time, this happens:
The mobile app can (and should) now discard the end user username and password, and instead make use of the access token; in case the access token expires, the mobile app cann use the refresh token to obtain a new access token (and refresh token).
This means that the mobile app does not need to keep the user's actual secrets; it has exchanged them for a purpose-tied pair of access and refresh tokens; even if the mobile app is hacked, the user's username and password are no longer present in the memory/storage of the mobile app, which obviously increases security.
In order to implement this use case with wicked.haufe.io, you will need one additional componenet which is not available in a standard deployment of wicked: An Authorization Server. The task of the Authorization Server for the Mobile Backend API Gateway use case is:
It's important to understand that wicked does neither impose any restrictions on how you verify user identity, nor on how the user is authorized. This can be done in a completely custom way, if needed.
An example implementation of an Authorization Server can be found at
This is a template for implementing exactly such a mobile backend Authorization Server, with
TODO sections to fill in.
If you decide to implement an Authorization Server based on node.js, the following wicked SDK libraries may help: