GeezerVison is showing github.com — Provide first-class (generated) code to support authentication/authorization · Issue #1524 · oapi-codegen/oapi-codegen
Provide first-class (generated) code to support authentication/authorization #1524DescriptionAs part of #1254 I'm looking at documenting the way that securitySchemes works, and it turns out it's a little more lackluster than I remember.
Right now, if you define an endpoint i.e.:
/apiKey:
get:
operationId: apiKey
description: Perform an authenticated request, using an API Key in the `X-API-Key` header
security:
- apiKey: []
responses:
# ... snip This generates only the following code:
@@ -20,7 +20,6 @@ import (
)
const (
+ ApiKeyScopes = "apiKey.Scopes"
BasicAuthScopes = "basicAuth.Scopes"
)
@@ -55,8 +54,6 @@ type MiddlewareFunc func(http.Handler) http.Handler
func (siw *ServerInterfaceWrapper) ApiKey(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
+ ctx = context.WithValue(ctx, ApiKeyScopes, []string{})
+
handler := http.Handler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
siw.Handler.ApiKey(w, r)
}))This still requires a lot of work to hand-roll server-side authentication.
We should instead generate
We can generated ??, and then rely on an implemented method sfor
multi reoutes
k
Although it can be possible to use the middleware to authenticate, I believe it's an area we can improve on.
We'll need to consider:
- the existence of the middleware(s) to not re-authenticate
- the existence of multiple means to authenticate - is it first one wins?
This should be opt-in.
Example schema:
Some code can be found in 09adbb0
See also:
#843
#177
#221
#911 Reacted by esprimo, Thore Göbel and Borhan Hafez Reacted by Khadim Fall, Jordi Burgos, Lâm Hoàng Phúc, markpsiano and esprimo Activityalehed commented on Jun 6, 2024 The current approach sort of works if you restrict yourself to one security scheme per endpoint. We are currently using a middleware which checks the request against the given authenticators. Using it looks something like this:
serverOptions := demo.ChiServerOptions{
...
Middlewares: []demo.MiddlewareFunc{
OAPICodegenAuthMiddleware(map[string]Authenticator{
api.ApiKeyScopes: ApiKeyAuthenticator(db),
api.BasicAuthScopes: BasicAuthenticator(usernamePasswordHashes),
})},
}alehed commented on Jun 6, 2024 For the issue with multiple security schemes per endpoint see #1644.
Our middleware currently resolves this problem by always assuming OR (which is the more common case) and disallowing AND-ing security schemes, but that has other drawbacks. mromaszewicz commented on Jun 6, 2024 IMO, putting anything to do with auth scopes into the generated code was a mistake, because it's a runtime behavior handled properly by openapi3filter. I have an API running at my workplace which has a complex specification with multiple schemes and it works ok.
I think we should deprecate authentication logic from the generated code altogether, and I'm happy to clean up the middleware or example to make it clear how to do this. Our middleware was written when openapi3filter was quite more primitive, and we could use it better today. juan-carvajal commented on Aug 4, 2025 What is the recommended way of getting the user context from a bearer token if using strict server? Should we just add the Authorization header as a required property in the models of each request? juan-carvajal commented on Aug 4, 2025
What is the recommended way of getting the user context from a bearer token if using strict server? Should we just add the Authorization header as a required property in the models of each request?
Just asking because in the strict handlers, there is no access to the raw request, so no way to get the header information...I guess you could always store the token info in the context via middleware (not ideal), but this feels like a missing feature especially when talking about JWT tokens which identify API consumers are can affect the request outcome. juan-carvajal commented on Aug 4, 2025
What is the recommended way of getting the user context from a bearer token if using strict server? Should we just add the Authorization header as a required property in the models of each request?
Just asking because in the strict handlers, there is no access to the raw request, so no way to get the header information...I guess you could always store the token info in the context via middleware (not ideal), but this feels like a missing feature especially when talking about JWT tokens which identify API consumers are can affect the request outcome.
Sorry, I am talking about the Golang server implementation, e.g:
func (h HTTPServer) GetModelGroups(ctx context.Context, request GetModelGroupsRequestObject) (GetModelGroupsResponseObject, error) {
// TODO implement me
r, err := h.application.Queries.GetModelGroups.Handle(ctx, query.GetModelGroups{
User: acl.NewUser("", "", request.Params.PartitionId), // HOW TO GET JWT TOKEN HERE
})
if err != nil {
return GetModelGroupsdefaultJSONResponse{
Body: ProblemDetails{},
StatusCode: 0,
}, nil
}
return GetModelGroups200JSONResponse{
{
Acl: nil,
Data: r[0].Data,
Description: r[0].Description,
Id: r[0].ID,
Legal: nil,
Name: r[0].Name,
},
}, nil
}mromaszewicz commented on Feb 7, 2026 Auth should be handled at runtime via openapi3filter, not generated code. The existing scopes constants in generated code were a design misstep and shouldn't be expanded further.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|