SupportConsoleDevelopersStart a trialContact

Chapter 5. OpenID Connect authentication

You can use OpenID Connect (OIDC) authentication with Connectivity Link to connect and secure an API exposed by a Gateway object.

5.1. Set the OIDC AuthPolicy custom resource
Copy link

You can configure a Connectivity Link AuthPolicy custom resource (CR) to use an OIDC provider. The same API deployed to multiple clusters can authenticate with the same identity provider.

In a zero-trust environment, every application with an HTTPRoute or GRPCRoute CR exposed by an application developer must also have an attached route-level AuthPolicy CR. You can target either a Gateway or a route object with an AuthPolicy CR.

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You created a Gateway object.
  • You created an HTTPRoute or GRPCRoute object.
  • You have a trusted OIDC provider configured to issue tokens for your API clients.
  • If your OIDC server is using a self-signed or internal cluster certificate, you injected the trusted CA bundle into your Connectivity Link installation.

Procedure

  1. Create an AuthPolicy CR that targets an HTTPRoute CR and configures OIDC authentication by using the following example:

    Example AuthPolicy CR

    apiVersion: kuadrant.io/v1
kind: AuthPolicy
metadata:
  name: <api_oidc_auth>
  namespace: <user_apps>
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: <api_route>
  rules:
    authentication:
      "oidc-idp-auth":
        jwt:
          issuerUrl: "https://rhbk.apps.cluster.example.com/realms/realm"

    • The AuthPolicy CR must exist in the same namespace where the HTTPRoute object is applied.
    • Replace the spec.metadata.name parameter value with the name you want to use for your AuthPolicy CR.
    • Replace the spec.metadata.namespace parameter value with the namespace where you want your AuthPolicy CR applied.
    • The value of the spec.targetRef.name parameter must match the name of your HTTPRoute object.
    • The URL, "https://rhbk.apps.cluster.example.com/realms/realm", is the base URL of your OIDC issuer, for example, Red Hat build of Keycloak.

  2. Apply your AuthPolicy CR by running the following command: 

    $ oc apply -f <api_oidc_auth.yaml>

    Replace <api_oidc_auth.yaml> with your AuthPolicy YAML filename.

5.1.1. Verify the OIDC AuthPolicy custom resource
Copy link

You can verify a Connectivity Link AuthPolicy custom resource (CR) after you applied the policy to ensure that it is working as intended.

Prerequisites

  • You completed the "Setting the OIDC AuthPolicy custom resource" procedure.

Procedure

  1. Check that your AuthPolicy has Accepted and Enforced status by running the following command: 

    $ oc describe authpolicy <api_oidc_auth> -n <user_apps>
    • Replace <api_oidc_auth> with the name of your AuthPolicy CR.
    • Replace <user_apps> with the namespace where your AuthPolicy CR is applied.

    Example output

    Status:
  Conditions:
    Last Transition Time:  2026-06-12T12:00:00Z
    Message:               AuthPolicy has been accepted
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2026-06-12T12:00:01Z
    Message:               AuthPolicy has been enforced
    Reason:                Enforced
    Status:                True
    Type:                  Enforced

  2. Send an unauthenticated request to your route to verify that it is blocked by running the following command: 

    $ curl -v -s -o /dev/null -w "%{http_code}\n" http://<route_hostname>
    • Replace <route_hostname> with the exposed hostname of your application route.

    Example output

    HTTP/1.1 401 Unauthorized

  3. Send an authenticated request containing a valid OIDC access token to verify that access is granted by running the following command: 

    $ curl -H "Authorization: Bearer <access_token>" -v -s -o /dev/null -w "%{http_code}\n" http://<route_hostname>
    • Replace <access_token> with a valid JWT string issued by your OIDC provider.
    • Replace <route_hostname> with the exposed hostname of your application route.

    Example output

    HTTP/1.1 200 OK

After you configured a Connectivity Link AuthPolicy custom resource (CR) to use an OIDC provider, you must get a token.

The following example assumes the following facts:

  • You have a Red Hat build of Keycloak instance running in the keycloak namespace that is listening at port 8080.
  • You have a kuadrant Keycloak realm.
  • You have a demonstration OAuth2 client with a Direct Access grant enabled.
  • You have a user john with the password p.

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You created a Gateway object.
  • You created an HTTPRoute or GRPCRoute object.
  • You created an AuthPolicy CR.

Procedure

  • Get an access token from within the cluster for the user John, who is assigned to the member role, by running the following command: 

    $ ACCESS_TOKEN=$(oc run token --attach --rm --restart=Never -q --image=curlimages/curl -- http://keycloak.keycloak.svc.cluster.local:8080/realms/kuadrant/protocol/openid-connect/token -s -d 'grant_type=password' -d 'client_id=demo' -d 'username=john' -d 'password=p' -d 'scope=openid' | jq -r .access_token)
    Note

    If your Red Hat build of Keycloak server is reachable from outside the cluster, you can get the token directly. Make sure that the hostname set in the OIDC issuer endpoint configured in the AuthPolicy CR matches the one used to get the token and is reachable from within the cluster.

You can configure role-based-access to use with your OpenID Connect (OIDC) authentication by adding the roles to your AuthPolicy custom resource (CR).

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You created a Gateway object.
  • You created an HTTPRoute or GRPCRoute object.
  • You created an AuthPolicy CR.
  • You got a token from your OIDC provider.

Procedure

  • Add the following roles to your AuthPolicy CR by using the following example:

    Example AuthPolicy with RBAC definitions

    apiVersion: kuadrant.io/v1
kind: AuthPolicy
metadata:
  name: <api_oidc_rbac_auth>
  namespace: <user_apps>
spec:
#...
  patterns:
    "member-role":
    - selector: auth.identity.realm_access.roles
      operator: incl
      value: member
    "admin-role":
    - selector: auth.identity.realm_access.roles
      operator: incl
      value: admin
  authorization:
    "rbac-resources-api":
      when:
      - cel: "http.path.matches('^/resources(/.)?$')" patternMatching: patterns: - patternRef: member-role "rbac-delete-resource": when: - cel: "http.path.matches('^/resources/\\\\d+$') && http.method == 'DELETE'" patternMatching: patterns: - patternRef: admin-role "rbac-admin-api": when: - cel: "http.path.matches('^/admin(/.)?$')"
      patternMatching:
        patterns:
        - patternRef: admin-role

  • Replace the spec.metadata.name parameter value with the name you want to use for your AuthPolicy CR.
  • Replace the spec.metadata.namespace parameter value with the namespace where you want your AuthPolicy CR applied.
  • Requests to /resources[/*] require the member role.
  • DELETE requests to ^/resources/\\\\d+$ require the admin role.
  • Requests to ^/admin(/.*)?$ require the admin role.

5.3.1. Verify RBAC with OIDC
Copy link

You can verify that the role-based-access you configured is working your OpenID Connect (OIDC) authentication by conducting tests with different user roles.

The following example assumes the following setup:

  • A Red Hat build of Keycloak instance running in the keycloak namespace listening at port 8080.
  • A kuadrant Red Hat build of Keycloak realm.
  • An OAuth2 client with Direct Access grant enabled.
  • A user john who is assigned the member role and has the password p.
  • A user jane who is assigned the member and admin roles and has the password p.

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You created a Gateway object.
  • You created an HTTPRoute or GRPCRoute object.
  • You configured an AuthPolicy CR with role-based-access.

Procedure

  1. Get an access token from within the cluster for the user John, who is assigned to the member role, by running the following command: 

    $ ACCESS_TOKEN=$(oc run token --attach --rm --restart=Never -q --image=curlimages/curl -- https://keycloak.keycloak.svc.cluster.local:8080/realms/kuadrant/protocol/openid-connect/token -s -d 'grant_type=password' -d 'client_id=demo' -d 'username=john' -d 'password=p' -d 'scope=openid' | jq -r .access_token)
    Note

    If your Red Hat build of Keycloak server is reachable from outside the cluster, you can get the token directly. Make sure that the hostname set in the OIDC issuer endpoint configured in the AuthPolicy CR matches the one used to get the token and is reachable from within the cluster.

  2. Retrieve your cluster base domain and assign it to an environment variable by running the following command: 

    $ export CLUSTER_DOMAIN=$(oc get ingress.config/cluster -o jsonpath='{.spec.domain}')

  3. As John, send a GET request to /resources by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" https://api.$CLUSTER_DOMAIN/resources -i

    Example output

    HTTP/1.1 200 OK

  4. As John, send a DELETE request to /resources/123 by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" -X DELETE https://api.$CLUSTER_DOMAIN/resources/123 -i

    Example output

    HTTP/1.1 403 Forbidden

  5. As John, send a GET request to /admin/settings by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" https://api.$CLUSTER_DOMAIN/admin/settings -i

    Example output

    HTTP/1.1 403 Forbidden

  6. Get an access token from within the cluster for the user Jane, who is assigned to the member and admin roles by running the following command: 

    $ ACCESS_TOKEN=$(oc run token --attach --rm --restart=Never -q --image=curlimages/curl -- http://keycloak.keycloak.svc.cluster.local:8080/realms/kuadrant/protocol/openid-connect/token -s -d 'grant_type=password' -d 'client_id=demo' -d 'username=jane' -d 'password=p' -d 'scope=openid' | jq -r .access_token)

  7. As Jane, send a GET request to /resources by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" https://api.$CLUSTER_DOMAIN/resources -i

    Example output

    HTTP/1.1 200 OK

  8. As Jane, send a DELETE request to /resources/123 by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" -X DELETE https://api.$CLUSTER_DOMAIN/resources/123 -i

    Example output

    HTTP/1.1 200 OK

  9. As Jane, send a GET request to /admin/settings by running the following command: 

    $ curl -H "Authorization: Bearer $ACCESS_TOKEN" https://api.$CLUSTER_DOMAIN/admin/settings -i

    Example output

    HTTP/1.1 200 OK

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top