datasette-auth-github 1.0 adds configurable 30-day GitHub login cookies for Datasette

datasette-auth-github is a Datasette plugin for GitHub authentication, not an authorization server or full identity-management system. The documented setup requires installing the plugin, creating a GitHub OAuth app, setting the callback URL to /-/github-auth-callback, and configuring client_id and client_secret in Datasette plugin configuration—preferably via environment variables rather than hard-coded metadata. datasette-auth-github · PyPI

Once signed in, the plugin produces a Datasette actor containing GitHub-derived fields such as id, display, gh_id, gh_login, gh_email, and optionally gh_orgs or gh_teams when organization/team loading is configured. datasette-auth-github · PyPI Access can then be controlled using Datasette allow rules, including restrictions by GitHub login, stable GitHub user ID, organization, or team membership. datasette-auth-github · PyPI

There is no AI model, inference endpoint, benchmark, token context length, or model safety card associated with this release.

Architecture

The plugin integrates with Datasette via the datasette plugin entry point and registers two routes: /-/github-auth-start and /-/github-auth-callback. The first route redirects users to GitHub’s OAuth authorization endpoint; the second exchanges the returned code for an access token, fetches the GitHub user profile, constructs a Datasette actor, and sets a signed ds_actor cookie. [](https://raw.githubusercontent.com/simonw/datasette-auth-github/1d47f69f5a38e36e8b8a861d42b1a3b722b09e8e/datasette_auth_github/__init__.py)

The OAuth flow aligns with GitHub’s documented web application flow: redirect to GitHub, redirect back to the application, then use the access token to call the GitHub API on behalf of the user. GitHub’s documentation describes this flow and the use of the access token for requests such as GET /user. Authorizing OAuth apps - GitHub Docs

The key new implementation detail is in views.py: DEFAULT_LOGIN_MAX_AGE is set to 30 * 24 * 60 * 60; verify_config() validates that login_max_age is either None or a positive integer; and the callback sets a signed ds_actor cookie with max_age=login_max_age. If login_max_age is not None, the plugin also places a signed expiry value in the cookie payload under "e", using a base62-encoded timestamp. [](https://raw.githubusercontent.com/simonw/datasette-auth-github/1d47f69f5a38e36e8b8a861d42b1a3b722b09e8e/datasette_auth_github/views.py)

That two-layer design matters. Max-Age controls browser retention, while the signed "e" value allows Datasette to reject an otherwise-present cookie after expiration. Datasette’s own authentication documentation describes this optional signed expiry timestamp mechanism for ds_actor cookies. Authentication and permissions - Datasette documentation

The cookie is set as HttpOnly, SameSite=Lax, path /, and Secure only when the request scheme is HTTPS. [](https://raw.githubusercontent.com/simonw/datasette-auth-github/1d47f69f5a38e36e8b8a861d42b1a3b722b09e8e/datasette_auth_github/views.py) MDN recommends HttpOnly for session identifiers and recommends Secure for cookies transmitted over HTTPS; it also notes that cookies without Expires or Max-Age are session cookies. Set-Cookie header - HTTP | MDN

Organization and team authorization

When load_orgs or load_teams is configured, the plugin requests the read:org OAuth scope; otherwise it requests user:email. [](https://raw.githubusercontent.com/simonw/datasette-auth-github/1d47f69f5a38e36e8b8a861d42b1a3b722b09e8e/datasette_auth_github/views.py) The helper code checks configured organizations and teams during sign-in and adds matching gh_orgs or gh_teams values to the actor. [](https://raw.githubusercontent.com/simonw/datasette-auth-github/1d47f69f5a38e36e8b8a861d42b1a3b722b09e8e/datasette_auth_github/utils.py)

This has an important revocation implication: organization and team memberships are captured at sign-in and persisted in the signed cookie. The 1.0 README explicitly warns that a removed user can continue to access the Datasette instance until the cookie expires or is invalidated; it recommends rotating DATASETTE_SECRET to invalidate existing cookies. datasette-auth-github · PyPI

Evaluation methodology and reproducibility

The documented test coverage is CI-based rather than an external evaluation. GitHub Actions shows a test workflow for the 1.0 commit with a matrix across Python 3.10, 3.11, 3.12, 3.13, and 3.14, and across Datasette dependency ranges "<1.0" and ">=1.0a20". The workflow installs the package, installs the matrix-selected Datasette version, and runs python -m pytest. Release version 1.0 · simonw/datasette-auth-github@1d47f69 · GitHub GitHub’s Actions page also shows the relevant test and publish workflows completing around the 1.0 release. 1.0 · simonw/datasette-auth-github@1d47f69 · GitHub

What is not documented: independent penetration testing, browser compatibility testing beyond the maintainer’s anecdote, formal threat modeling, load testing, or a complete test-result artifact accessible without GitHub login. The available workflow status supports “CI passed,” not “security verified.”

Datasette’s architecture deliberately leaves most authentication mechanisms to plugins. Its documentation says plugins can support authenticated users via cookies and API agents via tokens, and that each request has an associated actor value available as request.actor. Authentication and permissions - Datasette documentation datasette-auth-github fits this model by translating a GitHub OAuth identity into a Datasette actor and then relying on Datasette’s permission system for access control. datasette-auth-github · PyPI

The plugin is mature in the narrow sense that it has existed since 2019 on PyPI, with a history of releases through 2026. datasette-auth-github · PyPI But “1.0” should not be overread as an independent assurance claim. Here it appears to mean the maintainer considers the plugin stable enough, helped by compatibility testing against pre-1.0 and 1.0-alpha Datasette versions. Release: datasette-auth-github 1.0

The main security tradeoff is straightforward: longer-lived cookies improve usability but extend the window during which stale authorization data can be used. That is particularly relevant for org/team-based access because memberships are checked at sign-in and stored in the signed cookie. datasette-auth-github · PyPI

Operationally, teams should set login_max_age according to data sensitivity. A public demo may tolerate 30 days; an internal evaluation dashboard containing proprietary prompts, model outputs, customer data, or red-team results may require a shorter lifetime and a documented revocation process. Datasette’s signed expiry support helps, but it does not replace identity-provider-side session management or continuous authorization checks. Authentication and permissions - Datasette documentation

No conflicting independent evidence about the release was found in the reviewed sources. The main caveat is absence of independent corroboration: the bug report, fix rationale, and stability judgment all come from the maintainer or project infrastructure.

For business leaders, the practical takeaway is that this release lowers friction for GitHub-authenticated Datasette deployments. If your team uses Datasette for internal data catalogs, lightweight AI evaluation UIs, agent demos, or customer-facing prototypes, fewer unexpected logouts can improve usability.

For developers, the upgrade consideration is mostly configuration review:

• confirm datasette-auth-github==1.0 is installed;
• decide whether the 30-day default is appropriate;
• set login_max_age explicitly for regulated or sensitive deployments;
• use stable GitHub IDs rather than mutable usernames for critical allow rules;
• rotate DATASETTE_SECRET when org/team membership changes require immediate revocation;
• confirm HTTPS/proxy configuration so the cookie’s Secure behavior is correct in production.

For security teams, treat this as a session-management change, not as a new authentication assurance level.