Grant types

These are the grant types/flows for apps to get an access token on behalf of a user. If not included, the default will be ['client_credentials']. They take effect by being included 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 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
  # ...

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

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

check-circle-line exclamation-circle-line close-line
Scroll to top icon