Skip to content

oauth client restructuring#32

Merged
saucam merged 3 commits intomainfrom
ttl
Mar 26, 2026
Merged

oauth client restructuring#32
saucam merged 3 commits intomainfrom
ttl

Conversation

@saucam
Copy link
Copy Markdown
Contributor

@saucam saucam commented Mar 26, 2026

Summary


Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Chore (refactoring code, technical debt, workflow improvements)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (does not change functionality, e.g. code style improvements, linting)
  • This change requires a documentation update

Testing

  • Manually tested
  • Unit tests added/updated
  • No tests required

Impact / Risks


📸 Screenshots / Logs (if applicable)


@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a comprehensive restructuring of the OAuth client management system. The core OAuthClient domain model has been significantly expanded to support a richer set of client metadata and configuration options, adhering more closely to RFC 7591. This enhancement enables more flexible client registration, including per-client token lifetime settings and detailed client classification. The changes unify the client registration process in the service layer and provide an idempotent mechanism for ensuring client configurations in the server, making the system more robust and configurable.

Highlights

  • Enhanced OAuth Client Model: The OAuthClient domain model has been significantly expanded to include a wide array of new fields, aligning with RFC 7591 for dynamic client registration, supporting per-client token lifetimes, JWKS, software identity, and extensibility.
  • Unified Client Registration Logic: The service layer now features a single, comprehensive RegisterClient function that replaces separate logic for confidential and public clients, streamlining client creation with a new RegisterClientRequest struct.
  • Flexible Token Lifetime Configuration: OAuth clients can now specify custom AccessTokenTTL and RefreshTokenTTL values, allowing for fine-grained control over token expiration, with sensible defaults applied if not specified.
  • Idempotent Client Management: A new EnsureClient function has been introduced in the server, enabling idempotent creation or updating of OAuth clients based on configuration, without regenerating secrets on update.
  • Database Schema Update: The oauth_clients table schema has been extended to persist all the new fields introduced in the OAuthClient domain model.
  • API and Service Layer Refinements: The API handler for creating OAuth clients has been updated to accommodate the new fields, and the OAuth service logic for issuing and rotating tokens now respects the per-client TTL configurations.
  • Integration Tests: New tests were added to validate the per-client token TTLs and the idempotent update behavior of the EnsureClient function.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request significantly refactors OAuth2 client management to align with RFC 7591. Key changes include expanding the OAuthClient domain model with new fields like Description, ClientType, TokenEndpointAuthMethod, and per-client AccessTokenTTL/RefreshTokenTTL, with corresponding database schema updates. The client registration process is unified into a single RegisterClient service method, replacing separate confidential and public client registration. Token issuance logic now respects these per-client TTLs. A new EnsureClient function is added to idempotently create or update clients, replacing the previous EnsurePublicClient.

Feedback includes updating GetPublicClient to use the new client_type field for consistency, correcting the EnsureClient function's logic for updating slice fields to allow explicit clearing, removing redundant comments in domain/token.go, and improving error logging when fetching client details for TTL overrides in oauth.go.

clientType = "confidential"
authMethod = "client_secret_basic"
} else {
clientType = "public"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

With the introduction of the client_type field, other parts of the codebase that deal with public clients should be updated to use this field for checks.

Specifically, GetPublicClient (and its underlying repository method GetPublicByClientID) still seems to identify public clients by checking for an empty client_secret. This logic should be updated to check client_type = 'public' instead, to be consistent with the new data model. While the relevant code is not in this diff, this is a critical part of this refactoring to ensure correctness and maintainability.

@saucam saucam merged commit 9b3717d into main Mar 26, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants