Troubleshooting OAuth

You can find the answers to some common questions in the Developer Portal, or in support communities and forums in DeveloperWorks, on GitHub, or on Youtube.

You can use the following links to go to the topics:

Enable an extended error description

The OAuth 2.0 Authorization Framework governs how IBM® API Connect is defined. According to the specification, OAuth 2.0 error conditions trigger a payload with error, and an optional field error_description. To prevent information leakage, the IBM DataPower® Gateway default setting returns the error only. However, during the development and testing phase of an application, it is useful to find out why an OAuth 2.0 request is being rejected. To enable this behavior, the caller can pass an HTTP request header in the OAuth request:

APIm-Debug: true

The presence of the header enables the 'just-in-time' debugging for that OAuth transaction, and error_description is returned as part of the error condition. The output helps the caller to determine why an OAuth request is rejected by API Connect as shown in the examples.

Example error output without 'just-in-time' debugging:

{ "error":"invalid_request" }

Example error output with 'just-in-time' debugging:

{ "error":"invalid_request", "error_description":"Multiple OAuth client credentials are provided" }

OAuth 2.0 support in the developer portal test tool

OAuth 2.0 support is exposed as an API through the provider OpenAPI definition. You can use the test tool that is included with API Connect to test the OAuth 2.0 configuration. For more information, see Testing an API using the Developer Portal test tool.

OAuth requires quorum in a multi-node cluster

In a multi-node cluster, OAuth operations will fail if quorum is lost. Quorum requires that the number of active nodes is greater than 50% of the total number of nodes in the cluster.