OAuth Mocks
Local GitHub and Google OAuth provider mocks for development, end-to-end tests, CI, and no-network environments.
The mocks are stateless: authorization codes and access tokens carry the test identity, so no database or shared service is required.
Quick Start
Run both providers without installing anything permanently:
uvx oauth-mocks
This starts:
- GitHub at http://127.0.0.1:9001
- Google at http://127.0.0.1:9002
Install the command for regular use:
uv tool install oauth-mocks
oauth-mocks
oauth-mocks start is an equivalent explicit form.
CLI
Start only one provider:
oauth-mocks --provider github
oauth-mocks --provider google --port 9002
Choose the base port or bind address:
oauth-mocks --port 9100
oauth-mocks --host 0.0.0.0
Selected providers receive consecutive ports beginning at --port, in the
order supplied to --provider. Run oauth-mocks --help for all options.
Run from a Source Checkout
Install the locked development environment and run both mocks:
uv sync
uv run oauth-mocks
Each FastAPI app can also be run independently from its provider folder with auto-reload:
cd github
uv run fastapi dev --reload-dir ../src --port 9001
cd google
uv run fastapi dev --reload-dir ../src --port 9002
Provider Endpoints
GitHub:
| Endpoint | Description |
|---|---|
/login/oauth/authorize |
OAuth authorization form and submit endpoint |
/login/oauth/access_token |
OAuth token exchange |
/api/user |
Authenticated user profile |
/api/user/emails |
Authenticated user emails |
/api/user/installations |
GitHub App installations |
Google:
| Endpoint | Description |
|---|---|
/.well-known/openid-configuration |
OIDC discovery metadata |
/o/oauth2/v2/auth |
OAuth authorization form and submit endpoint |
/token |
OAuth token exchange |
/oauth2/v3/certs |
JWKS for ID token verification |
/oauth2/v2/userinfo |
Authenticated user profile |
Google ID tokens are signed with RS256, and the matching public key is exposed through the JWKS endpoint so applications can exercise their normal OIDC validation path.
Test Conventions
Email verification follows the same convention in both mocks:
| Email pattern | Verified |
|---|---|
unverified@* |
false |
| Any other email | true |
Using the client ID fail-client-id makes authorization and token exchange
fail intentionally.
Development
uv run pytest
uv build
Releases use RELEASE.md and AutoPub. The first automated release publishes
version 0.1.0 from the unreleased 0.0.0 baseline.
License
MIT
1 maintainer
Metadata
1 maintainer
Release files for oauth-mocks 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| oauth_mocks-0.1.0.tar.gz | 21.5 kB | Without provenance | Details for oauth_mocks-0.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| oauth_mocks-0.1.0-py3-none-any.whl | Python 3 | none | any | Details for oauth_mocks-0.1.0-py3-none-any.whl |
Total release size: 49.3 kB
Release files / oauth_mocks-0.1.0.tar.gz
| Download URL | oauth_mocks-0.1.0.tar.gz |
|---|---|
| Size | 21.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
842c1460e9356dc6cde30fc9a4a5f42148984de0ac6c29d8835e7510652330d8
|
|
BLAKE2b-256 checksum How to use checksums |
f6c9140070f22ee5c7d087c36c790316b755cd9f78a9782ec609da14dbf6ac06
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.11.28 {"installer":{"name":"uv","version":"0.11.28","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / oauth_mocks-0.1.0-py3-none-any.whl
| Download URL | oauth_mocks-0.1.0-py3-none-any.whl |
|---|---|
| Size | 27.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
246f7915160d2f486ba2b8a7b7f26aa3a1ba1a05424b37d0695a3309c74c6d50
|
|
BLAKE2b-256 checksum How to use checksums |
7a52400cc18afae6f34892b6e4f6210ada9c4951f4e7338ca1da06172c0183f2
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.11.28 {"installer":{"name":"uv","version":"0.11.28","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for oauth-mocks 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
