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.

Note

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.

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 opaque 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 an Authorization header. Retrieve the opaque access token from the Authorization header.

    Note

    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:

  4. AuthService: Check whether the HTTP request can be authenticated with the Kubernetes authenticator.

    Note

    When authenticating a client that has an access token granted from the external Identity Provider this check will fail.

Important

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: Request the UserInfo Endpoint of the external Identity Provider with the retrieved opaque access token in the Authorization header.

  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.

    Note

    If the access token is not valid, the external Identity Provider will respond with an error response. AuthService will then continue with the session authenticator. Find out more on the session 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

Summary

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.