OpenFn / OpenFn/lightning

[Spike] Simplify OAuth Client Creation Using Adaptor Schemas

Open
#3,104 1 comment 0 reactions 1 assignee View on GitHub

@elias-ba is already working on this.

Since Apr 10, 2025.

Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

Problem

Working with OAuth credentials in Lightning is hard, especially due to the complexity of how OAuth clients are currently created. While OAuth clients are essential to enable OAuth credentials, the process to configure them is too technical and error-prone for regular users.

At the moment, setting up an OAuth client requires:

  • An in-depth understanding of how OAuth works.
  • Familiarity with the specific OAuth provider.
  • Manual input of multiple URLs and scope values.

This complexity makes the experience frustrating even for experienced developers and admins, let alone other users. In most cases, users don’t care about creating OAuth clients. They just want to pick an adaptor and set up a credential that works.

Proposal

Let’s extend our existing adaptor-based schema approach to OAuth clients.

We already define credential types using adaptor schemas (configuration-schema.json), which Lightning uses to render the appropriate forms. We can apply the same idea to OAuth clients.

Plan
  • For each adaptor that supports OAuth, define a schema file (oauth-schema.json) that includes:
    • Required URLs (authorization, token, revocation, introspection, userinfo)
    • Required and optional scopes
  • When creating an OAuth client in Lightning, users would pick an adaptor.
    • This selection would auto-fill the relevant URLs and scopes.
    • The user would only need to provide the client_id and client_secret.
  • If someone still needs to set up a generic OAuth client (not covered by any adaptor), we retain the existing manual form.
Benefits
  • Massively improves UX for setting up OAuth clients.
  • Reduces risk of user errors.
  • Eliminates the need for duplicating detailed OAuth setup docs across adaptors.
  • Brings OAuth UX in line with how we already handle other credential types.
Mockup / Reference

Current form (see attached screenshot) is long, intimidating, and hard to fill out without prior knowledge:

Image

Next Steps
  • Validate if we can standardize the schema across major OAuth providers.
  • Identify which adaptors would benefit first (Google, Microsoft, etc.).
  • Define the schema structure for OAuth metadata (URLs + scopes).
  • Modify the UI to support schema-based OAuth client creation.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.