ApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 13. Integrating 3scale API Management with an OpenID Connect identity provider

To authenticate API requests, 3scale can integrate with an identity provider that complies with the OpenID Connect specification. For full compatibility with 3scale, the identity provider can be Red Hat single sign-on, Red Hat build of Keycloak, or a third-party identity provider that implements default Keycloak client registration. Any identity provider that implements OpenID Connect is compatible with the 3scale API gateway (APIcast).

Note

3scale does not use the RFC 7591 Dynamic Client Registration Mechanism. For full compatibility between 3scale and an OpenID Connect identity provider, there is a dependency on default Keycloak client registration.

The foundation for OpenID Connect is the OAuth 2.0 Authorization Framework (RFC 6749). OpenID Connect uses a JSON Web Token (JWT) (RFC 7519) in an API request to authenticate that request. When you integrate 3scale with an OpenID Connect identity provider, the process has two main parts:

  • APIcast parses and verifies the JWT in the request. If successful, APIcast authenticates the identity of the API consumer client application.
  • The 3scale Zync component synchronizes 3scale application details with the OpenID Connect identity provider.

3scale supports both of these integration points when Red Hat’s single sign-on technology or Red Hat build of Keycloak is the OpenID Connect identity provider. See the supported versions on the Supported Configurations page. However, the use of Red Hat’s single sign-on technology or Red Hat build of Keycloak is not a requirement. You can use any identity provider that supports the OpenID Connect specification and the default Keycloak client registration. APIcast integration is tested with Red Hat’s single sign-on, Red Hat build of Keycloak, and ForgeRock.

The following sections provide information and instructions for configuring 3scale to use an OpenID Connect identity provider:

13.1. Overview of integrating 3scale API Management and an OpenID Connect identity provider

Each main Red Hat 3scale API Management component participates in authentication as follows:

  • APIcast verifies the authenticity of the authentication tokens presented by API consumer applications. In a default 3scale deployment, APIcast can do this because it implements auto discovery of an API product’s OpenID Connect configuration.
  • API providers use the Admin Portal to set up authentication flows.
  • If a 3scale-managed API does not authenticate requests with standard API keys or with application identifier and key pairs, then API providers must integrate 3scale with an OpenID Connect identity provider. In the figure below, the OpenID Connect identity provider is Red Hat single sign-on.
  • With authentication configured and a live Developer Portal, API consumers use your Developer Portal to subscribe to an application plan that provides access to a particular 3scale API product.
  • When OpenID Connect is integrated with 3scale, subscription triggers the configured flow for API consumer applications to obtain JSON Web Tokens (JWTs) from the OpenID Connect identity provider. An API provider specifies this flow when configuring the API product to use OpenID Connect.

Figure 13.1. shows the main 3scale components with an OpenID Connect identity provider

Main 3scale components with OpenID Connect identity provider

After subscribing to an application plan, an API consumer receives authentication credentials from the integrated OpenID Connect identity provider. These credentials enable authentication of requests that an API consumer application sends to an upstream API, which is the API that is provided by the 3scale API product that the API consumer has access to.

Credentials include a client ID and a client secret. An application created by an API consumer uses these credentials to obtain a JSON Web Token (JWT) from the OpenID Connect identity provider. When you configure your 3scale integration with OpenID Connect, you select the flow for how an API consumer application obtains a JWT. In an API consumer application that uses the default Authorization Code flow with Red Hat’s single sign-on technology, the application must do the following:

  1. Initiate an OAuth authorization flow with the OpenID Connect identity provider before the first request to the upstream API backend. The authorization code flow redirects the end-user to Red Hat single sign-on. The end-user logs in to obtain an authorization code.
  2. Exchange the authorization code for a JWT.
  3. Receive a JWT from Red Hat single sign-on upon authentication.
  4. Send an API request that contains the JWT to the upstream API backend.
  5. Send subsequent API requests with the same JWT until it expires.
  6. Refresh the JWT or send a new request to the OpenID Connect identity provider to obtain a new JWT. Which action is required depends on the OpenID Connect identity provider.

APIcast receives requests from API consumers and checks the JWT in the request. If APIcast verifies the JWT, APIcast sends the request, including the JWT, to the upstream API backend.

Figure 13.2. shows that the OpenID Connect identity provider is Red Hat single sign-on but configuration with other OpenID Connect identity providers is possible.

Authentication of API requests

13.2. How APIcast processes JSON Web Tokens

APIcast processes each request by checking the JSON Web Token (JWT) that the OpenID Connect identity provider returned when it authenticated an API consumer application. The request contains the JWT in the format that was issued by the integrated OpenID Connect identity provider. The JWT must be in the Authorization header and it must use the Bearer schema. For example, the header should look like this: 

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbSIsInN1YiI6ImFiYzEyMyIsIm5iZiI6MTUzNzg5MjQ5NCwiZXhwIjoxNTM3ODk2MDk0LCJpYXQiOjE1Mzc4OTI0OTQsImp0aSI6ImlkMTIzNDU2IiwidHlwIjoiQmVhcmVyIn0.LM2PSmQ0k8mR7eDS_Z8iRdGta-Ea-pJRrf4C6bAiKz-Nzhxpm7fF7oV3BOipFmimwkQ_-mw3kN--oOc3vU1RE4FTCQGbzO1SAWHOZqG5ZUx5ugaASY-hUHIohy6PC7dQl0e2NlAeqqg4MuZtEwrpESJW-VnGdljrAS0HsXzd6nENM0Z_ofo4ZdTKvIKsk2KrdyVBOcjgVjYongtppR0cw30FwnpqfeCkuATeINN5OKHXOibRA24pQyIF1s81nnmxLnjnVbu24SFE34aMGRXYzs4icMI8sK65eKxbvwV3PIG3mM0C4ilZPO26doP0YrLfVwFcqEirmENUAcHXz7NuvA

There are a number of open source tools for securely decoding a JWT. Be careful that you do not decode a JWT in a public web tool. In a decoded JWT, you can see that the token has three parts:

  • The header provides information about how the token was formed and what algorithm was used to sign the token.
  • The payload identifies the API consumer that sent the request. The details can include the read and write actions that this API consumer can perform, an email address for the API consumer, and other information about the API consumer.
  • The signature is a cryptographic signature that indicates that the token has not been altered.

APIcast checks the JWT for the following characteristics:

  • Integrity

    Is the JWT being altered by a malicious user? Is the signature valid?

    The JWT contains a signature that the token’s receiver can verify to ensure that a known issuer signed the token. This verification also guarantees that its content remains as created. 3scale supports RSA signatures based on public/private key pairs. The issuer signs the JWT by using a private key. APIcast verifies the token by using a public key. APIcast uses OpenID Connect Discovery for getting the JSON Web Keys (JWK) that can be used to verify the JWT signature.

  • Timing

    Is the current time later than the time when the token becomes acceptable for processing? Has the JWT expired? In other words, APIcast checks the JWT nbf (not before time) and exp (expiration time) claims.

  • Issuer

    Was the JWT issued by an OpenID Connect identity provider that is known to APIcast? In other words, APIcast verifies that the issuer specified in the JWT is the same issuer that an API provider configured in the OpenID Connect Issuer field. Specification of the issuer is part of the procedure for integrating 3scale and an OpenID Connect identity provider. This is the JWT iss claim.

  • Client ID

    Does the token contain a 3scale client application ID that is known to APIcast? This client ID must match a ClientID Token Claim that the API provider specified in the procedure for integrating 3scale with the OpenID Connect identity provider. This is the JWT azp (authorized party that the JWT was issued to) claim and the aud (audience) claim.

If any JWT validation or authorization checks fail, APIcast returns an Authentication failed error. Otherwise, APIcast sends the request to the 3scale upstream API backend. The Authorization header remains in the request, so the API backend can also use the JWT to check the user and client identity.

13.3. How 3scale API Management Zync synchronizes application details with OpenID Connect identity providers

Zync is a 3scale component that reliably pushes data about 3scale applications to an OpenID Connect identity provider. In this interaction, a 3scale application corresponds to an OpenID Connect identity provider client. In other words, Zync communicates with the OpenID Connect identity provider to create, update, and delete OpenID Connect clients.

Zync implements Keycloak default client registration. The use of this API means that the client representation is specific to Keycloak and Red Hat’s single sign-on technology. The identity provider returns a client ID and a client secret, which are the authentication credentials for the 3scale application.

Each time 3scale creates, updates, or deletes an application, Zync communicates with the OpenID Connect identity provider to update the corresponding client accordingly. Successful synchronization requires the following settings for a given 3scale product:

  • The authentication mechanism is OpenID Connect.

  • The OpenID Connect Issuer Type is either:

    • Red Hat Single Sign-On when Red Hat Single Sign-On is the OpenID Connect identity provider. With this issuer type, Zync sends client registration requests to the Keycloak/Red Hat Single Sign-On default client registration API.
    • REST API for other OpenID Connect identity providers. With this issuer type, Zync sends client registration requests as shown in the Zync REST API example.
  • A URL such as the following is the OpenID Connect Issuer: http://id:secret@example.com/api_endpoint.

When deployed to an OpenShift cluster, there are two Zync processes:

  • zync

    Zync is a REST API that receives notifications from system-sidekiq and enqueues background jobs to zync-que. There are notifications for new, updated, and deleted 3scale applications.

  • zync-que

    Zync-que processes these background jobs, which communicate with system-app and with the OpenID Connect identity provider. For example, when Red Hat single sign-on is the configured OpenID Connect identity provider, Zync creates, updates and deletes clients in the single sign-on realm.

13.4. Integrating 3scale API Management with Red Hat single sign-on and Red Hat build of Keycloak as the OpenID Connect identity provider

As an API provider, you can integrate 3scale with Red Hat single sign-on (SSO) and Red Hat build of Keycloak as the OpenID Connect identity provider. The procedures documented here are for a 3scale API product that requires OpenID Connect for authenticating API requests.

Part of this procedure is to establish an SSL connection between 3scale Zync and SSO or Red Hat build of Keycloak, because Zync communicates with Red Hat’s single sign-on technology to exchange tokens. If you do not configure the SSL connection between Zync and single sign-on or Red Hat build of Keycloak, the tokens would be open for anyone listening.

3scale 2.2 and later versions support custom CA certificates for single sign-on with the SSL_CERT_FILE environment variable. This variable points to the local path of the certificates bundle. Integrating 3scale with single sign-on and Red Hat build of Keycloak as the OpenID Connect identity provider consists of configuring the following elements in the following order:

  • If SSO or Red Hat build of Keycloak does not use a certificate issued by a trusted Certificate Authority (CA), you must configure 3scale Zync to use custom CA certificates. This is not required if single sign-on uses a certificate issued by a trusted CA.
  • Configure single-sign on or Red Hat build of Keycloak to have a 3scale client.
  • Configure 3scale to work with SSO or Red Hat build of Keycloak.

Prerequisites

  • The single sign-on server must be available over HTTPS and it must be reachable by zync-que. To test this, you can run curl https://rhsso-fqdn from within the zync-que pod, for example: 

    $ oc rsh -n $THREESCALE_PROJECT $(oc get pods -n $THREESCALE_PROJECT --field-selector=status.phase==Running -o name | grep zync-que) /bin/bash -c "curl -v https://<rhsso-fqdn>/auth/realms/master"
  • OpenShift cluster administrator permissions.
  • A 3scale API product for which you want to configure OpenID Connect integration with single sign-on.

See the following sections for details:

13.4.1. Configuring 3scale API Management Zync to use custom Certificate Authority certificates

This is not required when SSO or Red Hat build of Keycloak use a certificate issued by a trusted Certificate Authority (CA). However, if SSO or Red Hat build of Keycloak do not use a certificate issued by a trusted CA you must configure 3scale Zync before you configure single sign-on to have a 3scale client and before you configure 3scale to work with single sign-on.

Procedure

  1. Obtain a CA certificate chain in .pem format and save each certificate as a separate file, for example: customCA1.pem, customCA2.pem, and so on.

  2. Test each certificate file to confirm that it is a valid CA. For example: 

    $ openssl x509 -in customCA1.pem -noout -text | grep "CA:"

    This outputs either CA:TRUE or CA:FALSE. You want the output to be CA:TRUE for each certificate file. If the output is CA:FALSE, the certificate is not a valid CA.

  3. Validate each certificate file with the cURL command below. For example: 

    $ curl -v https://<secure-sso-host>/auth/realms/master --cacert customCA1.pem

    Replace <secure-sso-host> with the fully qualified domain name of the single sign-on host.

    The expected response is a JSON configuration of the single sign-on realm. If validation fails, your certificate might not be correct.

  4. Gather the existing content of the /etc/pki/tls/cert.pem file on the zync-que pod: 

    $ oc exec <zync-que-pod-id> -- cat /etc/pki/tls/cert.pem > zync.pem

  5. Append the content of each custom CA certificate file to zync.pem, for example: 

    $ cat customCA1.pem customCA2.pem ... >> zync.pem

  6. Attach the new file to the zync-que pod as a configmap object: 

    $ oc create configmap zync-ca-bundle --from-file=./zync.pem

$ oc set volume deployment/zync-que --add --name=zync-ca-bundle --mount-path /etc/pki/tls/zync/zync.pem --sub-path zync.pem --source='{"configMap":{"name":"zync-ca-bundle","items":[{"key":"zync.pem","path":"zync.pem"}]}}'

    This completes the addition of the certificate bundle to the zync-que pod.

  7. Verify that the certificate is attached and the content is correct: 

    $ oc exec <zync-que-pod-id> -- cat /etc/pki/tls/zync/zync.pem

  8. Configure the SSL_CERT_FILE environment variable on Zync to point to the new CA certificate bundle: 

    $ oc set env deployment/zync-que SSL_CERT_FILE=/etc/pki/tls/zync/zync.pem

13.4.2. Configuring single sign-on to have a 3scale API Management client

In your OpenShift single sign-on (SSO) dashboard, configure SSO to have a 3scale client. This is a specialized, administrative client. Each time an API consumer subscribes to an API in your Developer Portal, 3scale uses the SSO administrative client that you create in this procedure to create a client for the API consumer application.

Procedure

  1. In the SSO console, create a realm for a 3scale client or select an existing realm to contain your 3scale client.
  2. In the new or selected realm, click Clients in the left navigation panel.
  3. Click Create to create a new client.
  4. In the Client ID field, specify a name that helps you identify this client as the 3scale client, for example oidc-issuer-for-3scale.
  5. Set the Client Protocol field to openid-connect.
  6. Save the new client.

  7. In the settings for the new client, set the following:

    • Access Type to confidential.
    • Standard Flow Enabled to OFF.
    • Direct Access Grants Enabled to OFF.

    • Service Accounts Enabled to ON. This setting enables this client to issue service accounts.

      1. Click Save.

  8. Set the service account roles for the client:

    1. Navigate to the Service Account Roles tab of the client.
    2. In the Client Roles drop down list, click realm-management.
    3. In the Available Roles pane, select manage-clients and assign the role by clicking Add selected >>.

  9. Note the client credentials:

    1. Make a note of the client ID (<client_id>).
    2. Navigate to the Credentials tab of the client and make a note of the Secret field (<client_secret>).

  10. To facilitate testing the authorization flow, add a user to the realm:

    1. On the left side of the window, expand Users.
    2. Click Add user.
    3. Enter a username, set Email Verified to ON, and click Save.
    4. On the Credentials tab, set the password. Enter the password in both fields, set the Temporary switch to OFF to avoid the password reset at the next login, and click Set password.
    5. When the pop-up window displays, click Set password.

13.4.3. Configuring 3scale API Management to work with single sign-on

Configure 3scale to work with Red Hat’s single sign-on technology (SSO) or Red Hat build of Keycloak by specifying integration settings in the 3scale Admin Portal.

Procedure

  1. In the 3scale Admin Portal, in the top level selector, click Products and select the 3scale API product for which you are enabling OpenID Connect authentication.
  2. Navigate to [Your_product_name] > Integration > Settings.

  3. Under Authentication , select OpenID Connect Use OpenID Connect for any OAuth 2.0 flow.

    Figure 13.3. displays the OPENID CONNECT (OIDC) BASICS section.

    OpenID Connect Basics
  4. In the OpenID Connect Issuer Type field, ensure that the setting is Red Hat Single Sign-On.

  5. In the OpenID Connect Issuer field, enter the URL for the configured OpenID Connect identity provider. The format for this URL looks like this: 

    https://<client_id>:<client_secret>@<rhsso_host>:<rhsso_port>/auth/realms/<realm_name>

  6. Replace the placeholders with the previously noted Red Hat Single Sign-On client credentials, the host and port for your Red Hat Single Sign-On server, and the name of the realm that contains the Red Hat Single Sign-On client.

    Note

    To use the same credentials across two different products, you must configure a unique OIDC issuer for each product or the same issuer, but a different realm. You can alternatively split applications into 2 separate products to use the same OIDC provider with the same realm for authentication. Refer to steps 5 and 6 for guidance.

  7. Under OIDC AUTHORIZATION FLOW, select one or more of the following:

    • Authorization Code Flow

      In Red Hat Single Sign-On this is the Standard Flow.

    • Implicit Flow

    • Service Accounts Flow

      Also referred to as Client Credentials Flow.

    • Direct Access Grant Flow

      Also referred to as Resource Owner Password Credentials.

      Figure 13.4. shows where you select the authorization flow:

      OpenID Connect Authorization Flow

      This configures how API consumers obtain JSON Web Tokens (JWTs) from the OpenID Connect identity provider. When 3scale integrates Red Hat Single Sign-On as the OpenID Connect identity provider, Zync creates Red Hat Single Sign-On clients that have only the Authorization Code Flow enabled. This flow is recommended as the most secure and suitable for most cases. Be sure to select an OAuth 2.0 flow that is supported by your OpenID Connect identity provider.

  8. Scroll down and click Update Product to save the configuration.
  9. In the left navigation panel, click Integration > Configuration.
  10. Scroll down to click Promote v. x to APIcast Staging.

Next steps

Test the integration with Red Hat Single Sign-On as the identity provider. When everything is working as it should, return to the Integration > Configuration page and scroll down to promote the APIcast staging version to be the production version.

13.5. Integrating 3scale API Management with third-party OpenID Connect identity providers

As an API provider, you can configure an HTTP integration between 3scale and a third-party OpenID Connect identity provider. That is, you can configure an OpenID Connect identity provider other than Red Hat’s single sign-on technology. 3scale uses this integration to authenticate requests from API consumers and to update the third-party identity provider with the latest 3scale application details.

Most of the work required to integrate 3scale with a third-party OpenID Connect identity provider involves these tasks:

  • Meeting the 3scale Zync-related prerequisites.
  • Configuring your OpenID Connect identity provider to authorize requests from 3scale applications.

Prerequisites

  • 3scale Zync is installed.

  • Your chosen third-party OpenID Connect identity provider:

    • Adheres to Zync’s OpenAPI specification as provided by 3scale.
    • Allows registration of a client with <client_id> and <client_secret> declared as a parameter in the request. 3scale is always the source of client identity management in the integration between 3scale and a third-party OpenID Connect identity provider.
    • Is configured for authorizing requests from 3scale applications.

  • If your configuration cannot fulfill the previous prerequisite, you must implement a custom adapter that is based on the Zync abstract adapter. Zync uses this adapter to interact with your OpenID Connect identity provider. To create this adapter, you can modify rest_adapter.rb, which is part of the 3scale Zync REST API example.

    You can include the rest_adapter.rb module in the zync-que pod according to the method that best fits your requirements. For example, you could mount a configMap through a volume, or you can build a new image for Zync.

Procedure

  1. In the 3scale Admin Portal, in the top level selector, click Products and select the 3scale API product for which you are enabling OpenID Connect authentication.
  2. Navigate to [Your_product_name] > Integration > Settings.

  3. Under Authentication, select OpenID Connect Use OpenID Connect for any OAuth 2.0 flow.

    This displays the OPENID CONNECT (OIDC) BASICS section.

  4. In the OpenID Connect Issuer Type field, ensure that the setting is REST API.

  5. In the OpenID Connect Issuer field, enter the URL for your OpenID Connect identity provider. The format for this URL looks like this: 

    https://<client_id>:<client_secret>@<oidc_host>:<oidc_port>/<endpoint>

    For example, in the Zync rest_adapter.rb example, the URL endpoint is hard-coded as {endpoint}/clients. Your endpoint might be {endpoint}/register or something else.

  6. Under OIDC AUTHORIZATION FLOW, select one or more of the following:

    • Authorization Code Flow
    • Implicit Flow
    • Service Accounts Flow
    • Direct Access Grant Flow

    This configures how API consumer applications receive JSON Web Tokens (JWTs) from the OpenID Connect identity provider. The Authorization Code Flow is recommended as the most secure and suitable for most cases. Be sure to select an OAuth 2.0 flow that is supported by your OpenID Connect identity provider.

  7. Scroll down and click Update Product to save the configuration.
  8. In the left navigation panel, click Integration > Configuration.
  9. Scroll down to click Promote v. x to APIcast Staging.

Next steps

Test the integration with the third-party identity provider. When everything is working as it should, return to the Integration > Configuration page and scroll down to promote the APIcast staging version to be the production version.

13.6. Testing 3scale API Management integrations with OpenID Connect identity providers

After integrating 3scale with an OpenID Connect identity provider, test the integration to confirm that:

  • API consumers receive access credentials when they subscribe to a 3scale-managed API.
  • APIcast can authenticate requests from API consumers.

Prerequisites

  • Integration between 3scale and your OpenID Connect identity provider is in place for a particular 3scale API product. This integration uses the Authorization Code Flow.
  • An application plan is available for API consumers to subscribe to in your Developer Portal. This application plan provides access to a 3scale-managed API, that is, a 3scale product, for which you configured OpenID Connect authentication.
  • An application that sends requests to the upstream API. The upstream API is a backend of the 3scale product that the API consumer application can access as a result of the subscription. Alternatively, you can use Postman to send requests.

Procedure

  1. In the Developer Portal, subscribe to an application plan.

    This creates an application in the Developer Portal. The OpenID Connect identity provider should return a client ID and a client secret that you can see in your application’s page in the Developer Portal.

  2. Note the client ID and the client secret for the application.
  3. Verify that your OpenID Connect identity provider now has a client with the same client ID and client secret. For example, when Red Hat’s single sign-on technology is the OpenID Connect identity provider, you will see a new client in the configured single sign-on realm.
  4. In the application page in the Admin Portal, in the REDIRECT URL field, enter the URL for the application that sends API requests to the upstream API.
  5. Verify that your OpenID Connect identity provider has the correct redirect URL.

  6. Discover the URL that receives authentication requests for your OpenID Connect identity provider by using this endpoint: 

    .well-known/openid-configuration

    For example: 

    https://<rhsso_host>:<rhsso_port>/auth/realms/<realm_name>/.well-known/openid-configuration
  7. For the base URL, use the value that an API provider configured in the OpenID Connect Issuer field.

  8. An API consumer, who is writing an application that consumes the upstream API, does the following:

    1. Initiates an authorization flow with your OpenConnect identity provider. This request must contain the 3scale application’s client ID and client secret. In some cases, the end-user identity is also required.
    2. Receives the identity provider’s response, which contains an authorization code.

  9. The API consumer’s application does the following:

    1. Exchanges the authorization code for a JWT.
    2. Receives a JWT from single sign-on upon authentication.
    3. Sends an API request that contains the JWT to the upstream API backend.

If APIcast accepts the JWT in the request, your application will receive a response from the API backend.

Alternatively, in place of an API consumer application, use Postman to test that the token flow is correctly implemented.

13.7. Example of a 3scale API Management integration with an OpenID Connect identity provider

This example shows the flow when you integrate 3scale with Red Hat’s single sign-on technology or Red Hat build of Keycloak as the OpenID Connect identity provider. This example has the following characteristics:

  • In the Admin Portal, an API provider defined a 3scale API product and configured that product to use single sign-on as the OpenID Connect identity provider.

  • This product’s OpenID Connect configuration includes:

    • Public base URL: https://api.example.com
    • Private base URL: https://internal-api.example.com
    • OpenID Connect Issuer: https://zync:41dbb98b-e4e9-4a89-84a3-91d1d19c4207@idp.example.com/auth/realms/myrealm
    • Authorization Code Flow, which is the standard flow, is selected.

  • In the 3scale Developer Portal, there is an application with the following characteristics. This application is the result of an API consumer subscribing for access to a 3scale API product provided by a particular application plan in the Developer Portal.

    • Client ID: myclientid
    • Client Secret: myclientsecret
    • Redirect URL: https://myapp.example.com

  • In single sign-on, in the myrealm realm, there is a client with these same characteristics:

    • Client ID: myclientid
    • Client Secret: myclientsecret
    • Redirect URL: https://myapp.example.com

  • The myrealm realm has this user:

    • Username: myuser
    • Password: mypassword
  • 3scale Zync client in myrealm has the correct Service Account roles.

The flow is as follows:

  1. An end-user (API consumer) sends an Authorization request to the authentication server, single sign-on in this example, at the following endpoint: 

    https://idp.example.com/auth/realms/myrealm/protocol/openid-connect/auth

    In the request, the application provides these parameters:

    • Client ID: myclientid
    • Redirect URL: https://myapp.example.com
  2. The application redirects the end-user to the single sign-on log-in window.

  3. The end-user logs in to single sign-on with these credentials:

    • Username: myuser
    • Password: mypassword
  4. Depending on the configuration, and whether this is the first time that the end-user is authenticating in this specific application, the consent window might display.
  5. Single sign-on issues an authorization code to the end-user.

  6. The API consumer application uses the following endpoint to send a request to exchange the authorization code for a JWT: 

    https://idp.example.com/auth/realms/myrealm/protocol/openid-connect/token

    The request contains the authorization code and these parameters:

    • Client ID: myclientid
    • Client secret: myclientsecret
    • Redirect URL: https://myapp.example.com.
  7. Single sign-on returns a JSON Web Token (JWT) with an access_token field such as eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lk…​xBArNhqF-A.

  8. The API consumer application sends an API request to https://api.example.com with a header such as: 

    Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lk…​xBArNhqF-A.
  9. The application should receive a successful response from https://internal-api.example.com.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.