Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time


  1. Please sign one of the contributor license agreements below.
  2. Fork the repo, develop and test your code changes, add docs.
  3. Make sure that your commit messages clearly describe the changes.
  4. Send a pull request.

Here are some guidelines for hacking on google-auth-library-python.

Making changes

A few notes on making changes to google-auth-library-python.

  • If you've added a new feature or modified an existing feature, be sure to add or update any applicable documentation in docstrings and in the documentation (in docs/). You can re-generate the reference documentation using nox -s docgen.
  • The change must work fully on the following CPython versions: 3.6, 3.7, 3.8, 3.9, 3.10 across macOS, Linux, and Windows.
  • The codebase must have 100% test statement coverage after each commit. You can test coverage via nox -e cover.

Testing changes

To test your changes, run unit tests with nox:

$ nox -s unit

Running system tests

You can run the system tests with nox:

$ nox -f system_tests/

To run a single session, specify it with nox -s:

$ nox -f system_tests/ -s service_account

First, set the environment variable GOOGLE_APPLICATION_CREDENTIALS to a valid service account. See Creating and Managing Service Account Keys for how to obtain a service account.

Project and Credentials Setup

Enable the IAM Service Account Credentials API on the project.

To run system tests locally, you will need to set up a data directory

$ mkdir system_tests/data

Your directory should look like this. Follow the instructions below for creating each file.



Use the gcloud CLI to get an authorized user file

$ gcloud auth application-default login --scopes=,,openid

You will see something like:

Credentials saved to file: [/usr/local/home/.config/gcloud/application_default_credentials.json]

Copy the contents of the file to authorized_user.json.

Open the IAM page of the Google Cloud Console. Grant the user the Service Account Token Creator Role. This will allow the user to impersonate service accounts on the project.


Follow Creating and Managing Service Account Keys to create a service account.

Copy the credentials file to service_account.json.

Grant the account associated with service_account.json the following roles.

  • App Engine Admin (for App Engine tests)
  • Service Account Token Creator (for impersonated credentials and workload identity federation tests)
  • Pub/Sub Viewer (for gRPC tests)
  • Storage Object Viewer (for impersonated credentials tests)
  • DNS Viewer (for workload identity federation tests)
  • GCE Storage Bucket Admin (for downscoping tests)


Follow Creating and Managing Service Account Keys to create a service account.

Copy the credentials file to impersonated_service_account.json.


In order to run the workload identity federation tests, you will need to set up a Workload Identity Pool, as well as attach relevant policy bindings for this new resource to our service account. To do this, make sure you have IAM Workload Identity Pool Admin and Security Admin permissions, and then run:

$ ./scripts/

and then use the output to replace the variables near the top of system_tests/system_tests_sync/

App Engine System Tests

To run the App Engine tests, you wil need to deploy a default App Engine service. If you already have a default service associated with your project, you can skip this step.

Edit app.yaml so service is default instead of google-auth-system-tests. From system_tests/app_engine_test_app run the following commands

$ pip install --target lib -r requirements.txt
$ gcloud app deploy -q app.yaml

After the app is deployed, change service in app.yaml back to google-auth-system-tests. You can now run the App Engine tests:

$ nox -f system_tests/ -s app_engine

Compute Engine Tests

These tests cannot be run locally and will be skipped if they are run outside of Google Compute Engine.

grpc Tests

These tests use the Pub/Sub API. Grant the service account specified by GOOGLE_APPLICATION_CREDENTIALS permissions to list topics. The service account should have at least roles/pubsub.viewer.

Coding Style

This library is PEP8 & Pylint compliant. Our Pylint config is defined at pylintrc for package code and pylintrc.tests for test code. Use nox to check for non-compliant code:

$ nox -s lint

Documentation Coverage and Building HTML Documentation

If you fix a bug, and the bug requires an API or behavior modification, all documentation in this package which references that API or behavior must be changed to reflect the bug fix, ideally in the same commit that fixes the bug or adds the feature.

To build and review docs use nox:

$ nox -s docs

The HTML version of the docs will be built in docs/_build/html


This library follows Semantic Versioning.

It is currently in major version zero (0.y.z), which means that anything may change at any time and the public API should not be considered stable.

Contributor License Agreements

Before we can accept your pull requests you'll need to sign a Contributor License Agreement (CLA):

  • If you are an individual writing original source code and you own the intellectual property, then you'll need to sign an individual CLA.
  • If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA.

You can sign these electronically (just scroll to the bottom). After that, we'll be able to accept your pull requests.