Repository navigation
feat(oauth): add client branding support for OAuth authorization pages - #9
Conversation
|
@aspiers is attempting to deploy a commit to the Hypercerts Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
f7139d4 to
22c2def
Compare
There was a problem hiding this comment.
Pull request overview
This PR adds client branding support for OAuth authorization pages, allowing trusted OAuth clients to inject custom CSS to maintain visual consistency during the authentication flow. The implementation restricts this feature to clients explicitly marked as trusted in the PDS configuration to prevent unauthorized UI manipulation.
Changes:
- Added
branding.cssfield to OAuth client metadata schema with comprehensive documentation - Modified CSS building logic to inject client-specific CSS only for trusted clients
- Updated authorization page rendering to compute client-specific CSS per request
- Added example branding CSS in sds-demo demonstrating custom button styling and brand indicators
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| packages/oauth/oauth-types/src/oauth-client-metadata.ts | Adds optional branding object with css field to client metadata schema |
| packages/oauth/oauth-provider/src/customization/build-customization-css.ts | Extends CSS building function to conditionally inject client branding CSS for trusted clients only |
| packages/oauth/oauth-provider/src/router/assets/send-authorization-page.ts | Moves CSS generation from factory-level to per-request to support dynamic client branding |
| packages/sds-demo/rollup.config.js | Adds example branding CSS with custom colors, button styling, and brand indicator |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Generate CSS with client branding | ||
| const customizationCss = cssCode( | ||
| buildCustomizationCss({ | ||
| branding: customization.branding, | ||
| clientMetadata: data.client.metadata, | ||
| isTrusted: data.client.info.isTrusted, | ||
| }), | ||
| ) |
There was a problem hiding this comment.
The CSS generation has been moved from pre-computation (line 17 in the factory function) to per-request computation inside the handler function. This creates a performance regression because buildCustomizationCss will be called for every authorization request instead of once when the factory is initialized.
For authorization pages that don't use client branding (non-trusted clients or clients without branding), this adds unnecessary overhead on every request. Consider maintaining the pre-computed customizationCss for the base case and only computing client-specific CSS when needed.
There was a problem hiding this comment.
Filed as #14 to be done as a follow-up.
| /* Add a subtle brand indicator */ | ||
| .auth-form::before { | ||
| content: "Powered by SDS Demo"; | ||
| display: block; | ||
| text-align: center; | ||
| font-size: 0.75rem; | ||
| color: rgb(99 102 241); | ||
| margin-bottom: 1rem; | ||
| } |
There was a problem hiding this comment.
The pseudo-element selector '.auth-form::before' assumes that an element with class 'auth-form' exists in the authorization page markup. If this class doesn't exist or is renamed in the future, the branding indicator won't be displayed. Consider documenting the expected DOM structure for custom CSS, or use more defensive CSS that won't break if the structure changes.
Without this patch, OAuth clients cannot customize the appearance of authorization pages when users authenticate. All clients see the same default Bluesky branding regardless of their identity. This is a problem because trusted third-party applications (like the SDS demo) may want to provide a branded experience during the OAuth flow to maintain visual consistency and user trust. This patch solves the problem by: - Adding a `branding.css` field to OAuth client metadata schema - Allowing trusted clients (configured in PDS trustedClients) to inject custom CSS into authorization pages - Enhancing sds-demo to include example branding CSS The branding CSS is only applied for clients marked as trusted in the PDS configuration, preventing untrusted clients from manipulating the authorization UI. Co-authored-by: Claude <noreply@anthropic.com>
22c2def to
2789990
Compare
Without this patch, OAuth clients cannot customize the appearance of
authorization pages when users authenticate. All clients see the same
default Bluesky branding regardless of their identity.
This is a problem because trusted third-party applications (like the
SDS demo) may want to provide a branded experience during the OAuth
flow to maintain visual consistency and user trust.
This patch solves the problem by:
branding.cssfield to OAuth client metadata schemacustom CSS into authorization pages
The branding CSS is only applied for clients marked as trusted in the
PDS configuration, preventing untrusted clients from manipulating the
authorization UI.
Co-authored-by: Claude noreply@anthropic.com