Configure grant types

This topic tells you how to configure grant types for Application Single Sign-On (commonly called AppSSO).

Apps use grant types or flows to get an access token on behalf of a user. If not included, the default grant type is ['client_credentials']. You must include these grant types in the authorizationGrantTypes property list in the Client Registration.

To register a client/application, apply the yaml with your specifications to your cluster kubectl apply -f <path-to-your-yaml>.

Topics

• Client Credentials Grant
• Authorization Code Grant

Client Credentials Grant Type

This grant type allows an application to get an access token for resources about the client itself, rather than a user.

Dynamic Client Registration (via ClientRegistration custom resource):

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClientRegistration
metadata:
  name: <your client name>
spec:
  authorizationGrantTypes:
    - client_credentials
  # ...

Note

Ensure that you are able to retrieve a token through your setup

1. Apply your ClientRegistration

   kubectl apply -f <path-to-the-clientregistration-yaml>
   

2. Verify your ClientRegistration was created

   kubectl get clientregistrations
   

   –> you should see a ClientRegistration with the name you provided

3. Verify your Secret was created

   kubectl get secrets
   

   –> you should see a Secret with that same name you provided for the ClientRegistration

4. Get the client secret and decode it

   kubectl get secret <your-client-registration-name> -o jsonpath="{.data.client-secret}" | base64 -d
   

5. Get the client id (or get it from your configuration)

   kubectl get secret <your-client-registration-name> -o jsonpath="{.data.client-id}" | base64 -d
   

6. Request token

   curl -X POST <AUTH-DOMAIN>/oauth2/token?grant_type=client_credentials -v -u "YOUR_CLIENT_ID:DECODED_CLIENT_SECRET"
   

Authorization Code Grant Type

This grant type allows clients to exchange this code for access tokens.

Dynamic Client Registration (via ClientRegistration custom resource):

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClientRegistration
metadata:
  name: <your client name>
spec:
  authorizationGrantTypes:
    - authorization_code
  scopes:
     - openid
  # ...

Note

Ensure that you are able to retrieve a token through your setup

Ensure there is an Identity Provider configured

1. Get your authserver’s label name

   kubectl get authserver sso4k8s -o jsonpath="{.metadata.labels.name}"
   

2. Apply this sample ClientRegistration (read more about ClientRegistrations

   The following is an example ClientRegistration that will work in this setup. The required scopes are openid, email, profile, roles. The redirect URI here has been set to match that of oauth2-proxy.

   apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
   kind: ClientRegistration
   metadata:
    name: oauth2-proxy-client
    namespace: <your-namespace>
   spec:
    authServerSelector:
    matchLabels:
      name: <your-authserver-label-name>
    authorizationGrantTypes:
      - client_credentials
      - authorization_code
    requireUserConsent: false
    redirectURIs:
      - http://127.0.0.1:4180/oauth2/callback
    scopes:
      - name: openid
      - name: email
      - name: profile
      - name: roles
   

   kubectl apply -f <path-to-the-clientregistration-yaml>
   

3. Verify your ClientRegistration was created

   kubectl get clientregistrations
   

   –> you should see a ClientRegistration with the name you provided

4. Verify your Secret was created

   kubectl get secrets
   

   –> you should see a Secret with that same name you provided for the ClientRegistration

5. Get the client secret and decode it

   CLIENT_SECRET=$(kubectl get secret <your-client-registration-name> -o jsonpath="{.data.client-secret}" | base64 -d)
   

6. Get the client id (or get it from your configuration)

   CLIENT_ID=$(kubectl get secret <your-client-registration-name> -o jsonpath="{.data.client-id}" | base64 -d)
   

7. Get the issuer uri

   ISSUER_URI=$(kubectl get secret <your-client-registration-name> -o jsonpath="{.data.issuer-uri}" | base64 -d)
   

8. Use the oauth2-proxy to spin up a quick trial run of the configured Authserver and run it with docker.

   docker run -p 4180:4180 --name oauth2-proxy bitnami/oauth2-proxy:latest \
   --oidc-issuer-url "$ISSUER_URI" \
   --client-id "$CLIENT_ID" \
   --insecure-oidc-skip-issuer-verification true \
   --client-secret "$CLIENT_SECRET" \
   --cookie-secret "0000000000000000" \
   --http-address "http://:4180" \
   --provider oidc \
   --scope "openid email profile roles" \
   --email-domain='*' \
   --insecure-oidc-allow-unverified-email true \
   --upstream "static://202" \
   --oidc-groups-claim "roles" \
   --oidc-email-claim "sub" \
   --redirect-url "http://127.0.0.1:4180/oauth2/callback"
   

   Note

   Ensure that your issuer URL does not resolve to 127.0.0.1.

9. Check your browser at 127.0.0.1:4180 to see if your configuration allows you to sign in.

   You should see a message that says “Authenticated”.