Authentication with External Identity Providers Using JWT

This guide describes how AuthService performs authentication for client requests that use an access token in JSON Web Token (JWT) format from an external Identity Provider (such as PingID).

Note

In this guide, we use Client instead of User as the actor of the described Step-by-Step Analysis. AuthService can authenticate both users and programmatic clients based on their JWT access token. A programmatic client is an application of the user that can make distinct requests. Therefore, AuthService must authenticate the programmatic client that made the request.

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

  • Integration of your Arrikto EKF installation with an external Identity Provider.
  • An access token from your external Identity Provider.
  • Configure the AuthService to perform local access token validation.
  • Configure the AuthService with the proper audiences.

Step-by-Step Analysis

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

When a client makes a request with a JWT access token in their Authorization header:

  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 AuthService.

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

  4. AuthService: Check if this token targets the Kubernetes API server.

    Note

    When authenticating a client locally based on their JWT access token, that the external Identity Provider granted for them, this check will fail.

  5. AuthService: Check if this token targets the external identity authenticator.

    Note

    If the token:

    • is not in JWT format, or
    • does not have the expected issuer (iss) or audience (aud) for the external Identity Provider

    then this authenticator fails and AuthService will proceed with the rest of the available authenticators.

  6. AuthService: Examine the token expiration time (exp) and validate that the token has not expired.

    Note

    If the token has expired then AuthService responds to Istio Gateway with HTTP 401. Alternatively, AuthService proceeds with the following steps.

  7. AuthService: Validate the signature (sig) of the token, based on the key ID (kid) referenced in the token.

    Note

    AuthService validates the signature as such:

    • if the kid corresponds to a JWK of the cached JWKS, then AuthService validates the signature of the token. If the signature is not valid then AuthService responds to Istio Gateway with HTTP 401.

    • if the kid does not correspond to a JWK of the cached JWKS, then:

      1. AuthService: Make a request to the JWKS Endpoint to fetch the new keys.
      2. Identity Provider: Respond to AuthService with the JWKS.
      3. AuthService: Cache the new JWKS.
      4. AuthService: If the kid is in the cached JWKS, then validate the signature (sig).

      If either the kid does not correspond to a JWK of the cached JWKS or the signature is not valid, then AuthService responds to Istio Gateway with HTTP 401.

  8. AuthService: Retrieve the UserID and the groups of this client.

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

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

  11. 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:

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

Warning

Validating an access token locally with AuthService comes at a cost. Since AuthService acts as an authentication proxy and not as an Identity Provider, it cannot learn about revoked tokens. This means that AuthService will treat a revoked access token as valid, until it expires. We strongly advise you to use access tokens with short expiration times, or configure AuthService to send the access token to the external Identity Provider.

See also

Summary

In this guide you gained insight on how AuthService performs authentication for client requests that use a JWT 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.

PreviousNext