OpenAPITools / OpenAPITools/openapi-generator

[REQ] [Go] Support ApiKey or BearerToken with the go-server generator

Open
#22,565 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Is your feature request related to a problem? Please describe.

Currently none of the security features are supported by the go-server generator.
This makes it difficult

Describe the solution you'd like

At a minimum, a good first step would be having at least one of the features implemented.
I proposed ApiKey or BearerToken as they seem the most general and easiest to handle and/or pass through specially compared to OAuth or OpenIDConenct.

I'm not sure on how best to handle the parsing of the session information (i.e. token/user etc), the way I did a proof-of-concept was by using the context.,

In this case I passed it straight through:

ctx := context.WithValue(r.Context(), "user", r.Header.Get("APIKey"))
// Where APIKey comes from the securitySchemes.token.name where securitySchemes.token.type == "apiKey".

But ideally on a per-service basis you would want to be able to write code that maps the API key to a user ID/email or some kind of other session ID so each respective route could query that (and then it potentially wouldn't need to worry about what kind of method for security was used down stream).

Server Author

As the server author, you exposed with the ability to write a function that provides your own code to handle how to handle the API Key, Bearer token, etc and convert it to appropriate object for use by the API endpoints, such that you can query active identity (user/session) and optionally was the request authenticated.

Bonus

Check the security requirements of operations and generate corresponding checks and error conditions.

This likely would be better raised as a separate issue if its not done to satisfied this request, however without any handling at all for security schemas its not doable.

Describe alternatives you've considered

There doesn't seem to be a nice way already to do this.

The other idea, I had would be to utilise the mux routing to handle the authentication.
This would be better than requiring each generated control function needing to handle authentication.
This one is something I might take a look at doing as that could mean the auth would only require one change in the generated main() function.

The alternative router supported by the generator chi, seems to support this as well through its middleware handler.

Additional context

I fairly new to Go so I am really not sure what the best way to do this, but I figure best to at include some ideas.

Contributor guide

Open the contributing guide

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.

Research direction

Start by tracing the go-server generator's generated main() and mux or chi routing, then inspect how OpenAPI securitySchemes are represented for apiKey and bearer authentication. Compare the context-based proof of concept with the requested per-service authentication hook; done should include a defined handling path for at least one scheme and generated behavior that matches it.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, openapi
Domain
api, authentication, backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.