API Authentication

Red Hat 3Scale 2.0

For Use with Red Hat 3Scale 2.0

Red Hat Customer Content Services

Abstract

This guide documents methods for api authentication with Red Hat 3Scale 2.0.

Chapter 1. Authentication Patterns

By the time you complete this tutorial you’ll know how to set the authentication pattern on your API and the effect this has on applications communicating with your API.

Depending on your API you may need to use different authentication patterns to issue credentials for access to your API. These can range from API keys to openAuth tokens and custom configurations. This tutorial covers how to select between the standard Authentication Patterns Available.

1.1. Authentication Patterns

3scale supports the following authentication patterns out of the box:

  • Standard API Keys: single randomized strings or hashes acting as an identifier and a secret token.
  • Application Identifier and Key pairs: immutable identifier and mutable secret key strings.
  • OAuth 2.0: OAuth 2.0 client id, client secret and access token combinations.

1.2. Extensions

3scale also offers commercially reasonable support for coupling issues credentials with IP address filtering or referrer domain filtering – see the extra section at the end of this tutorial.

1.3. Step 1: Select the Authentication mode for your service.

Once in your Administration Dashboard, navigate to the API tab and select the service you wish to work on (there may be only one service named API in which case select this). Click on the Integration Link.

Select Authentication Mode Step 1

Note that each service you operate could use a different authentication pattern, but only one pattern can be used per service.

It is not recommended you change the authentication pattern once credentials have already been registered since behavior may be unpredictable. To change authentication patterns we recommend creating a new service and migrating customers.

1.4. Step 2: Select the Auth Mode you want to use

Scroll down to the Authentication section an choose the required Authentication mode.

Select Authmode Step 2

1.5. Step 3: Ensure your API accepts the right types of Credentials

Depending on the credential type chosen, you will likely need to accept different parameters in your API calls (key fields, IDs etc.). The names of these parameters need not be the same as those used internally at 3scale, your 3scale authentication will function correctly just as long as the correct parameter names are used in calls to the 3scale backend.

1.6. Step 4: Create an application to test credentials

In order to test the credential sets are working you can create a new application to issue credentials to use the API. Navigate to the Accounts area of your dashboard, click on the account you wish to use and click the new application button.

Filling out the form and clicking save will create a new application with credentials to use the API. You can now use these credentials to make calls to your API and records will be checked against 3scale list of registered applications.

1.7. Standard Authentication Patterns

3scale supports the following authentication patterns out of the box.

1.7.1. API Key

The simplest form of credentials supported is the single API model. Here each application with permissions on the API has a single (unique) long character string something like this:

    API-key = 853a76f7c8d5f4a1ee8bf10a4e0d1f13

By default the name of the key parameter is user_key. You can use this same label or choose another such as API-key in which case you simply need to map the value over before you make the authorization calls to 3scale. The string acts as both an identifier and a secret token for use of the API. It is recommended such patterns are only used either in environments with low security requirements or with SSL security on API calls. The operations which can be carried out on the token and application are:

  • Application Suspend: this suspends the applications access to the API and in effect all calls to the API with the relevant key will be suspended
  • Application Resume: undoes the effect of an application suspend action
  • Key Regenerate: this action generates a new random string key for the application and associates it with the application. Immediately after this action is taken calls with the previous token will cease to be accepted.

The latter action can be triggered from the API Administration dashboard and (if permitted) from the API Developers User console.

1.7.2. App_ID and App_Key Pair

Whereas the API Key Pattern combines the identity of the application and the secret usage token in one token, this pattern separates the two. Each application using the API issues an immutable initial identifier known as the Application ID (App ID). The App ID is constant and may or may not be secret. In addition each application may have 1-n Application Keys (App_Keys). Each Key is associated directly with the App_ID and should be treated as secret.

    app_id = 80a4e03 app_key = a1ee8bf10a4e0d1f13853a76f7c8d5f4

In the default setting, developers are able to create up to 5 keys per application. This allow a developer to create a new key, add it to their code redeploy their application and then disable old keys – causing no application downtime as an API Key Regeneration would.

Note that statistics and rate limits are always kept at the application ID level of granularity and not per API Key. If a developer wishes to track two sets of statistics, they should create two applications rather than two keys.

It is also possible to change mode in the system and allow applications to be created without applications keys present. In this case the 3scale system will authenticate access based on the App ID only (and no key checks are made). This mode is useful for (for example) widget type scenarios or where rate limits are applied to users rather than applications. Note that in most cases you will want your API to enforce there to be at least one application key per application present (this setting can be found on the Settings menu item under usage rules).

1.7.3. openAuth Support

openAuth is a set of specifications which enable a variety of different authentication patterns for APIs. The two major versions released so far (v1 and v2) are significantly different and version 2 includes a number of different supported authentication flows.

1.7.4. More Information

If you have authentication needs which are not covered by this how to, let us know by contacting support.

In addition, 3scale supports coupling credentials with authorized IP ranges per key or referrer domains per key to restrict where specific API credentials can be used. You can enable this additional filtering by navigating to the API Tab and accessing the Settings screen on the API.

Legal Notice

Copyright © 2018 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.