Skip to content

Support for Authentication Definitions (Security Schemes) like OpenAPI #54

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
HatsuneMiku3939 opened this issue Mar 11, 2025 · 0 comments

Comments

@HatsuneMiku3939
Copy link

Description

Thank you for providing such a great tool for generating API client and server code from Go interfaces!

However, it currently lacks a way to define authentication methods (such as API keys, JWT, or OAuth2) directly within the Oto interface definitions.

In OpenAPI, we can specify security schemes (e.g., http, oauth2, apiKey) to define authentication requirements for different endpoints. It would be very helpful if Oto provided a similar mechanism to declare authentication requirements, so that authentication could be automatically enforced or documented in the generated code.

Proposed Solution

  • Introduce a way to define authentication within the Oto interface, similar to OpenAPI security schemes.
  • Possible approaches:
    1. Add a struct tag (e.g., @auth:"bearer" for authentication).
    2. Define authentication at the service level using a special interface or annotation.
    3. Generate authentication middleware automatically in the output code.

Example

A possible Oto-style interface might look like:

// @auth:"bearer"
type ProtectedService interface {
    SecureMethod(ctx context.Context, req AuthenticatedRequest) (Response, error)
}

This would indicate that SecureMethod requires authentication via a Bearer token.

Benefits

  • Simplifies authentication handling in Oto-generated services.
  • Improves security by enforcing authentication at the interface level.
  • Makes it easier to integrate Oto with existing authentication standards.

Would love to hear thoughts from the maintainers and community on whether this would be a useful addition!
Thank you!

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

No branches or pull requests

1 participant