About

Review some common options that you might want to use in your OAuth external auth policies for authorization codes. For more information, see the API reference.

Basic configuration example

The example configuration snippets on this page are based on the following external auth configuration for Google accounts.

  apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: ratings-google
  namespace: bookinfo
spec:
  applyToRoutes:
  - route:
      labels:
        oauth: "true"
  config:
    server:
      name: ext-auth-server
      namespace: bookinfo
      cluster: $CLUSTER_NAME
    glooAuth:
      configs:
      - oauth2:
          oidcAuthorizationCode:
            appUrl: http://localhost:8080
            callbackPath: /callback
            clientId: ${CLIENT_ID}
            clientSecretRef:
              name: google
              namespace: bookinfo
            issuerUrl: https://accounts.google.com
            scopes:
            - email
            session:
              cookieOptions:
                notSecure: true

Cookies

Store cookies so that your users do not have to authenticate for each subsequent API request. You can customize cookie behavior, such as to change the path, age, or domain.

  apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: ratings-google
  namespace: bookinfo
spec:
  config:
    glooAuth:
      configs:
      - oauth2:
          oidcAuthorizationCode:
            session:
              cookieOptions:
                notSecure: true
                maxAge: 3600
                path: "/docs"
                domain: "example.com"

Review the following table to understand this configuration. For more information, see the API reference.

SettingDescription
notSecureSet to true to use an insecure cookie. Insecure cookies can be used for demos and testing purposes, but are not recommended for production.
maxAgeThe max age of the cookie in seconds. Leave unset for a default of 30 days (2592000 seconds). To disable cookie expiry, set to 0.
pathThe path of the cookie. If unset, the path defaults to "/". To avoid setting a path, enter "". If you use a directory separator, subdirectories are matched as well. For example, /docs matches request paths /docs, /docs/, and /docs/gloo-mesh/, but does not match /, /docset/, or /en/docs.
domainThe domain to which the cookie is sent. By default, this value is empty and matches only the domain of the originating request, not including subdomains. The default setting works if the originating request and the redirect target of the identity provider (IdP) match. However, you must set this value if the IdP redirects the request to another subdomain. For example, consider the case where the virtual gateway matches requests to *.example.com, and the IdP redirects the auth requests to subdomain.example.com. If you do not set the domain value, requests fail that come in on subdomains like docs.example.com. The user is still redirected to the IdP login as expected. However, because the request originates from a different subdomain, the token-bearing cookie is not sent back to the proxy. Therefore, authentication fails. In contrast, if you set domain to example.com, authentication succeeds because the cookie is sent to any subdomain of example.com.

Store sessions in Redis

By default, the OIDC tokens are saved in a secure, client-side cookie. Instead, you can set up Gloo Mesh Gateway to store the OIDC tokens in Redis. Gloo Mesh Gateway generates a random session ID for the user’s cookie that is stored client-side.

  apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: ratings-google
  namespace: bookinfo
spec:
  config:
    glooAuth:
      configs:
      - oauth2:
          oidcAuthorizationCode:
            session:
              failOnFetchFailure: true
              redis:
                cookieName: session
                options:
                  host: redis.gloo-mesh.svc.cluster.local:6379

Review the following table to understand this configuration. For more information, see the API reference.

SettingDescription
cookieNameThe name of the cookie to set and store the session ID. If unset, the default name is "__session”.
options.hostThe address of the Redis instance to use, in the format address:port or unix://path-to-unix.sock. The example stores sessions in the default Redis instance that runs in the gloo-mesh namespace.
options.dbThe Redis database to use, indexed to start at 0. This example does not specify a database, so the default 0 is used.
options.poolSizeThe maximum number of connections to establish at once. This example does not specify a pool size, so the default of 10 connections per CPU is used.

Logout URL

You can set a logout URL. When users access this URL, their user session and cookie are deleted. If you don’t set up a logout URL, logout functionality is disabled.

  apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: ratings-google
  namespace: bookinfo
spec:
  config:
    glooAuth:
      configs:
      - oauth2:
          oidcAuthorizationCode:
            logoutPath: /logout
            afterLogoutURL: http://localhost:8080/home/

Review the following table to understand this configuration. For more information, see the API reference.

SettingDescription
logoutPathEnter a path relative to the appUrl for users to log out of an OIDC session. When this URL is accessed, the user session information is deleted, and a 200 OK response is returned.
afterLogoutURLBy default, users are returned to the URL that is set in appURL. To change this behavior, add a full URL in this field, such as http://localhost:8080/home/.

Forward the ID token

Configure Gloo Mesh Gateway to forward the ID token to the destination in a header after successful authentication. For example, your app might need the ID token for further processing.

  apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: ratings-google
  namespace: bookinfo
spec:
  config:
    glooAuth:
      configs:
      - oauth2:
          oidcAuthorizationCode:
            headers:
              idTokenHeader: "x-token"

Review the following table to understand this configuration. For more information, see the API reference.

SettingDescription
idTokenHeaderThe header name to use to forward the ID token. This example sets the header name to x-token.