OpenID Connect with Google

Because OpenID Connect deals with user credentials, all transactions should take place over HTTPS. Although user passwords for third party identity providers are only submitted to those providers and not Kong, authentication tokens do grant access to a subset of user account data and protected APIs, and should be secured. As such, you should make Kong’s proxy available via a fully-qualified domain name and add a certificate for it.

Before configuring Kong, you’ll need to set up a Google APIs project and create a credential set. Following Google’s instructions, with the Web application class. Add an authorized redirect URI for part of the API you wish to protect (more complex applications may redirect to a resource that sets additional application-specific state on the client, but for our purposes, any protected URI will work). Authorized JavaScript origins can be left blank.

If you have not yet , go ahead and do so. Again, note that you should be able to secure this Service with HTTPS, so if you are configuring a host, use a hostname you have a certificate for.

Add a plugin with the configuration below to your Service using an HTTP client or Kong Manager. Make sure to use the same redirect URI as configured earlier:

Depending on your needs, it may not be necessary to associate clients with a consumer. You can, for example, configure the parameter to limit access to a internal users if you have a G Suite hosted domain, or configure upstream_headers_claims to send information about the user upstream (e.g. their email, a profile picture, their name, etc.) for use in your applications or for analytics.

Consumer Mapping

If you need to interact with other Kong plugins using consumer information, you must add configuration that maps account data received from the identity provider to a Kong consumer. For this example, we’ll map the user’s Google account email by setting a custom_id on their consumer, e.g.

curl -i -X POST http://kong:8001/consumers/ \
  --data username="Yoda" \
curl -i -X PATCH http://kong:8001/services/{SERVICE_NAME}/plugins/{OIDC_PLUGIN_ID} \
  --data config.consumer_by="custom_id" \

This also requires that clients login using an account mapped to some consumer, which may not be desirable (e.g. you apply OpenID Connect to a service, but only use plugins requiring a consumer on some routes). To deal with this, you can set the anonymous parameter in your OIDC plugin configuration to the ID of a generic consumer, which will then be used for all authenticated users that cannot be mapped to some other consumer.