Mobile API Gateway

Securing Mobile APIs using the OAuth2 Resource Owner Password Flow

Use Case Description

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.

You can now leverage the "local" authentication method of wicked to store your mobile users email addresses and passwords. Wicked can act as a full featured identity provider for your mobile backend, i.e. be a full mobile backend, including authentication and authorization.

 

Development Time Workflow

For development time, the following workflow is typical:

  1. The developer signs up for the API Portal and registers the mobile application in the portal, using a trusted subscription
  2. By creating a subscription to the Mobile API, the developer obtains client credentials for the mobile application, a client ID and a client secret; for this use case, only the client ID is significant
  3. The developer incorporates the client ID into the mobile application and implements the needed bits for the OAuth2.0 Resource Owner Password Grant Flow.

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.

The wicked Authorization Server would also reject calls using the Resource Owner Password Grant from public applications presenting their client secret, and vice versa.

Runtime Workflow

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:

  1. The mobile app presents a login screen which asks for username and password of the end user
  2. Using the client ID, the username and password, the mobile app uses the OAuth 2.0 Resource Owner Password Grant Flow to ask an Authorization Server for an access token to the backend API
  3. The Authorization Server verifies the username and password, and if successful, issues both an Access Token and a Refresh Token for the mobile App to use
  4. Whenever the mobile app now uses the access token, all requests to the backend API will be enriched with the identity (and possibly scope) of the request

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.

 

How do I implement this with wicked?

Wicked packs brings all the necessary components to implement this out of the box:

  • Wicked stores usernames and passwords, and if needed, can also ask new users for additional information (registration information).
  • The wicked Authorization Server automatically creates suitable endpoints so that your API can only be accessed using access tokens which are created using this endpoint.
  • When your backend API is called from the Gateway Proxy, and a valid access token is presented, Kong will automatically inject who is calling (as X-Authenticated-UserId), which application is calling the API on behalf of the user.
  • You can leverage this injected information to do further checking on the user as your business logic requires, but wicked makes sure that only well-known users are being let through to your API.

In case you implement using node.js, you can also leverage the wicked SDK to have even more influence on the user and registration management. Read up on the wicked SDK here:

In a future version, wicked will also support the PKCE enhancement of the Authorization Code Grant (see RFC 7636) and OAuth2 for native apps (see RFC 8252). This will enable even more flexible authentication scenarios for mobile/native applications.


Back to top

© 2016-2018 Haufe-Lexware GmbH & Co. KG, www.haufe-lexware.com, www.haufe.de, www.lexware.de, www.haufe-akademie.de