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).
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.
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:
Client: Perform HTTP request to Kubeflow with an access token in the Authorization header.
Istio Gateway: Intercept the HTTP request and send it to AuthService.
AuthService: Check whether the HTTP request has an Authorization header. Retrieve the JWT access token from the Authorization header.
AuthService: Check if this token targets the Kubernetes API server.
When authenticating a client locally based on their JWT access token, that the external Identity Provider granted for them, this check will fail.
AuthService: Check if this token targets the external identity authenticator.
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.
AuthService: Examine the token expiration time (
exp) and validate that the token has not expired.
If the token has expired then AuthService responds to Istio Gateway with
HTTP 401. Alternatively, AuthService proceeds with the following steps.
AuthService: Validate the signature (
sig) of the token, based on the key ID (
kid) referenced in the token.
AuthService validates the signature as such:
kidcorresponds 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
kiddoes not correspond to a JWK of the cached JWKS, then:
- AuthService: Make a request to the
JWKS Endpointto fetch the new keys.
- Identity Provider: Respond to AuthService with the JWKS.
- AuthService: Cache the new JWKS.
- AuthService: If the
kidis in the cached JWKS, then validate the signature (
If either the
kiddoes not correspond to a JWK of the cached JWKS or the signature is not valid, then AuthService responds to Istio Gateway with
- AuthService: Make a request to the
AuthService: Retrieve the UserID and the groups of this client.
AuthService: Respond to Istio Gateway that the client was successfully authenticated (
HTTP 200status), and set the UserID header for this client.
Istio Gateway: Forward the request to Kubeflow with the UserID header.
Kubeflow: Perform the action that the client requested and respond back to Istio Gateway.
See more on how Kubeflow performs authorization by using Kubernetes RBAC:
Istio Gateway: Forward the response to the client.
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.
- Find out how you can perform Authentication with External Identity Providers using Opaque Tokens, in order to let AuthService validate each request by asking the external Identity Provider.
- Find out about the Identity Providers that you can integrate your Arrikto EKF deployment with.
- Find out about the JSON Web Key Set (JWKS).
- Find out more regarding the Bearer Token usage by checking The OAUTH 2.0 Authorization Framework: Bearer Token Usage proposed standard.
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.
The next guide presents how the AuthService performs authentication with OpenID Connect (OIDC) when a user makes a request with no credentials.