OAuth introspection for third-party OAuth providers
OAuth token validation can be offloaded to the third-party Open Authorization (OAuth)/Open ID Connect (OIDC) provider by using the Introspection URL. Clients can use a third-party OAuth or OIDC provider to obtain a token that is protected by API Connect. IBM® API Connect can use this feature along with the mentioned provider to protect access to the API.
You can use API Connect to protect an API that is secured by using the third-party OAuth access token in accordance with
Introspection specification as defined in RFC 7662. In addition to the specification, the
x-Introspect-
header is provided to pass other content to the third party as you
require.
Authentication information can be carried in the request by configuring a basic authentication request header.
The following sequence diagram depicts the overall flow of request and response. The purpose of this diagram is only to provide a general visualization of the nature of the flow; for the precise details, refer to the explanatory information after the diagram.
The Introspect URL is configured in the Third Party OAuth provider configuration. See Configuring a third-party OAuth provider.
When an API is protected by a third-party OAuth provider, API Connect will extract the bearer token and issue an HTTP POST request to the endpoint specified in the Introspect URL field.
The GET request is protected by API Connect with this feature.
x-introspect-*
.
GET /petstore/pet/123 HTTP/1.1
Host: apiconnect.com
x-Introspect-type: dog
x-Introspect-name: simon
x-custom-apic: petstore123
Authorization: Bearer tGzv3JOkF0XG5Qx2TlKWIA
x-IBM-Client-Id: xxx-xxx
However, if you want to use a different header prefix, specify the
required value in the Custom header pattern field in the third party OAuth
provider configuration. For third-party OAuth provider configuration details, see Configuring a third-party OAuth provider. The Custom header pattern feature is
available only with the DataPower® API Gateway, if you are using
the DataPower Gateway (v5 compatible) the header
prefix must be x-Introspect-
.
x-tokenIntrospect
, as illustrated in the code
sample: POST /oauth/introspectURL HTTP/1.1
Host: apiconnect.ibm.com
Content-Type: application/x-www-form-urlencoded
x-Introspect-type: dog
x-Introspect-name: simon
x-custom-apic: petstore123
token_type_hint=access_token&token=tGzv3JOkF0XG5Qx2TlKWIA
The third party OAuth/OIDC provider will respond with HTTP 200 indicating the request was successful and that payload contains the token information. API Connect honors the active claim as defined in the RFC specification.
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{ “active”:true,
“token_type”:“bearer”,
“client_id”:“xxx-xxx”,
“username”:“John Smith”,
...
}
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"active":false
}
A response code other than HTTP 200
indicates failure to process the
request.
When the OAuth token is valid and active, context variables are populated with information from the introspect JSON response. For more information, see API Connect context variables.
When contacting the introspection endpoint, API Connect uses
client_id
/appId
and
client_secret
/appSecret
to construct the HTTP Basic authorization
header.
x-introspect-basic-authorization-header
exists in the request,
the value is used for the HTTP Basic authentication header when the introspection endpoint is
contacted. API Connect
verifies that the HTTP Basic authentication header value is Base64 encoded before it is sent, and
encodes it if necessary as shown in the following example. If the header is already encoded, it is
sent without
modification.GET /petstore/pet/123 HTTP/1.1
Host: apiconnect.com
x-introspect-basic-authorization-header: user:password
API Connect issues the
following:POST ..
Authorization: Basic M3JkLXBhcnR5LWNsaWVudF9pZDozcmQtcGFydHlfY2xpZW50X3NlY3JldA==token_type_hint=access_token&token= ..
scope validate url
are configured, and if the
response is an active token with a scope claim from the third-party OAuth Provider introspection
endpoint, API Connect will further enforce the scope validation in the following order: - If
scope
is configured for the OAuth API protection, verify the third-party scope against the scope that is configured. - If
scope validation url
is configured, verify the third-party scope against the scope validation URL. - If the third-party OAuth provider introspection endpoint does not return a scope, the Gateway will not check the scope defined in the security definition of the API where the third-party OAuth provider resource is used. For details on configuring an OAuth security definition in an API, see Creating an OAuth security definition.
- Supply a
suppress-parameters
header as follows:suppress-parameters: client_id
orsuppress-parameters: scope
depending on which parameters you want to suppress.suppress-parameters: client_id scope
- Define an API property called
suppress-parameters
in the API definition itself, with one of the following string values:client_id
orscope
depending on which parameters you want to suppress. For information on how to define API properties, see Setting API properties.client_id scope