Using Third-party Access Tokens For Access Control

IDP is connected to SecureAuth and has the token exchange enabled in its settings.

The IDP must be Okta, Auth0, or any IDP connected using the SecureAuth's OIDC Generic Connector.

This article is based on the natively supported by SecureAuth Auth0 IDP.

You have an access token obtained from your IDP through a client application registered within this IDP. You are going to exchange this token for SecureAuth's access token.

If your IDP uses any custom claims, you have created corresponding claims in SecureAuth and mapped them to the attributes in the IDP's configuration in SecureAuth.

Gateway is set up in SecureAuth and a service is deployed behind it.

For the purpose of this article, an Istio Service Mesh is deployed on Kubernetes using the acp-on-k8s GitHub repository . The service mesh exposes the httpbin.org service.

You can use any gateway/service mesh and expose any service behind it.

An authorizer created within the same workspace as your IDP with token exchange and APIs that you deployed behind your gateway are discovered.

You can use any authorizer. This article is based on SecureAuth integration with Istio Service Mesh using Istio Authorizer.

3rd Party Token Providers (Identity providers) are enabled in your authorizer's settings.

Configuring Trusted IDPs

In the 3rd Party Tokens tab of your authorizer's settings, you can set trusted IDPs. Authorizers exchange tokens only for the trusted IDPs. If only one IDP in your workspace has the token exchange grant enabled, it is configured as trusted by default and it cannot be changed.

In SecureAuth, go to your discovered APIs and apply an authorization policy that requires an access token to be present in the request.

For the purpose of this article, an authorization policy that always accepts a request is applied to the httpbin GET /anything endpoint to illustrate the token exchange. The GET /anything API always returns anything that is passed in the request data so it is possible to see which token is passed to the service to authenticate the client.

1. In SecureAuth, go to Authorization > Policies > + CREATE POLICY.

2. Create an API request SecureAuth policy with a name and ID of your choice.

3. Remove the Fail validator and add the Pass validator.

4. Save your changes.

5. Go to APIs and apply your new policy to the GET /anything API from the httpbin service.

Get a token from your IDP and copy it. For tips, see the second step in prerequisites.

Make a request to the API that is protected by your authorizer with the policy that you have applied in the first step.

To make a request to the httpbin service deployed on Kubernetes using the acp-on-k8s GitHub repository you need to execute your request from one of your Kubernetes pods.

1. Create a sleep pod in your K8s container by executing the following commands in your terminal:

   kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/sleep/sleep.yaml                     

2. Check for pods in your Default Kubernetes namespace.

   kubectl get pods
   NAME                       READY   STATUS    RESTARTS   AGE
   httpbin-7fb9b9479b-9xtlw   1/1     Running   0          5h5m
   sleep-557747455f-wqrjh     2/2     Running   0          18s                     

3. Execute into the shell of your sleep container.

   kubectl exec -it sleep-557747455f-wqrjh sh                     

4. Call your protected API.

   curl http://httpbin:80/anything -H "Authorization: Bearer $AT"                     

   $AT is an environment variable which value points to the third-party access token.

   Requesting Scopes

   The exchanged token that the authorizer receives from SecureAuth can include the same scopes as there are in the 3rd party access token provided that the scopes exist in SecureAuth. If you want any custom scopes to be requested, add them in SecureAuth to replicate the scopes that are included in the third-party access token and assign them to your authorizer's client application.

   If it is not possible to get the same scopes, all scopes assigned to the client application are requested.

   The openid and offline_access scopes are filtered out to avoid issuing any additional tokens.

In Auth0, create an Auth0 Rule that is responsible for adding attributes to a user.

Choose the Add attributes to a user for specific connection template.

Replace the template's snippet with the following:

function addAttributes(user, context, callback) {

var namespace = 'https://example.com/';
   user.groups = ['user','admin'];

   context.idToken[namespace + 'groups'] = user.groups;

callback(null, user, context);
}               

This script defines a list of hardcoded groups the user belongs to and adds them to the ID token so that SecureAuth can get them by calling the IDP's /userinfo endpoint. The custom attribute follows Auth0's covnention for prefixing custom claims through URL.

In SecureAuth, go to your workspace Settings > Claims > Access Tokens.

Add a groups claim with the source type set to AuthN Context and a source path set to groups.

Go to Identities > your Auth0 IDP > Attributes.

Add an Attribute with:

In the Mappings tab, add a mapping from the https://example\.com/groups source name to the List of groups that user belongs to target name.

Get access token from your Auth0 IDP.

Call your protected API.

curl http://httpbin:80/anything -H "Authorization: Bearer $AT"               

$AT is an environment variable which value points to the third-party access token you got from Auth0.

The httpbin GET /anything API returns a JSON with anything that was passed in the request.

Get the access token that you can find in your request response and decode it using the JWT decoder