Authentication with External Identity Providers using Opaque Tokens

This guide describes how AuthService performs authentication for client requests that use an opaque access token from an external Identity Provider (such as PingID).

Here’s what you’ll need so that you can authenticate with an external IdP using an opaque token:

  • Integration of your Arrikto EKF installation with an external Identity Provider.
  • An opaque access token from your external Identity Provider.
  • AuthService must be configured to perform remote access token validation.


You can use this method of authentication even if you use a JWT as an access token. In this case, the AuthService will simply treat it as an opaque token, meaning that it will not check its claims and all the following steps will apply.

Under construction

This feature is a work in progress.

Step-by-Step Analysis

Here is a step-by-step explanation of how AuthService authenticates clients based on their opaque access token.

  1. Client: Perform HTTP request to Kubeflow with an access token in the Authorization header.

  2. Istio Gateway: Intercept the HTTP request and send it to the AuthService.

  3. AuthService: Check whether the HTTP request has a cookie.


    When authenticating with an external IdP, the client does not have a cookie, so this check will fail. The client has an Authorization header granted from the external Identity Provider.

  4. AuthService: Check whether the HTTP request has an Authorization header. Retrieve the access token from the Authorization header.


    If the client makes a request with no credentials, this check will also fail. AuthService will then perform the authentication via the OIDC Authorization Code Flow. Find out more about this authentication method here:


If the AuthService caching mechanism is enabled and the retrieved Bearer token exists in the cache, then AuthService will skip both Step 5 and Step 6 (see the respective dotted arrows in the above diagram). You can find out more on how to enable the AuthService caching mechanism in the Enable AuthService Caching Mechanism guide.

  1. AuthService: Send the access token to the Token Introspection Endpoint of the external Identity Provider.

  2. AuthService: Retrieve the User ID and the groups of the user from the successful response of the external Identity Provider, using the USERID_CLAIM and GROUPS_CLAIM configuration options of AuthService.


    If the access token is not valid, the external Identity Provider will respond with an error response. AuthService will then continue with the Kubernetes authenticator. Find out more on the Kubernetes authenticator here:

  3. AuthService: Respond to Istio Gateway that the client was successfully authenticated (HTTP 200 status) and set the UserID header for the client.

  4. Istio Gateway: Forward the request to Kubeflow with the UserID header.

  5. Kubeflow: Perform the action that the client requested and respond back to Istio Gateway.

    See also

    See more on how Kubeflow performs authorization by using Kubernetes RBAC:

  6. Istio Gateway: Forward the response to the client.

See also


In this guide you gained insight on how AuthService performs authentication for client requests that use an opaque access token from an external Identity Provider.

What’s Next

The next guide presents how the AuthService performs authentication with OpenID Connect (OIDC) when a user makes a request with no credentials.