You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently developing an API that makes use of OAuth2 Password Flows and need to be able to authenticate to use it.
Currently, there is no OAuth2 specific code, but for my use case, merely allowing me to declare the Authorization header would already solve my issue. However, there is no way (that I know of) of declaring arbitrary headers on the generated code.
I'm already modifying my OpenAPI schema to handle #558 (comment) but would appreciate more escape hatches on the Swift side.
To that end, I am keen on helping implementing the generation for either the escape hatch or the Authorization header on the presence of OAuth security schemes. Just tell me where to look into!
Long term, it'd be great to see a proposal of how to better support OAuth2 in the generated code. I don't think we've come up with a design yet, and we welcome the community proposing one (using our Proposal process).
I'm currently developing an API that makes use of OAuth2 Password Flows and need to be able to authenticate to use it.
To that end, I am keen on helping implementing the generation for either the escape hatch or the Authorization header on the presence of OAuth security schemes. Just tell me where to look into!
Perhaps this piece of code modesty named RefreshTokenAuthMiddleware might be useful to you. It's not OAuth2, but it's a refresh token authentication scenario. You might be able to reuse some of the approaches.
I'm no expert on Modern Concurrency, but I've tried to make use of it.
Is it supported to call next() more than once inside intercept()?
If the server responds with 401, the middleware can obtain a new access token using the refresh token, and then retry the request before returning the response, all without bothering the caller. I'd rather not wrap all API calls with that logic.
I know the client could do that periodically before expiration and pass the new token to the middleware, but there might be other reasons for the server to return 401.
Activity
czechboy0 commentedon Apr 5, 2024
Hi @jmg-duarte,
you're right that there is no special code generated for OAuth2 flows yet, that's a missing feature: https://swiftpackageindex.com/apple/swift-openapi-generator/1.2.1/documentation/swift-openapi-generator/supported-openapi-features#OAuth-Flows-Object
In the short term, we recommend folks implement a
ServerMiddlewareand add any auth information as a task local, as shown in this example: https://github.com/apple/swift-openapi-generator/tree/main/Examples/auth-server-middleware-exampleLong term, it'd be great to see a proposal of how to better support OAuth2 in the generated code. I don't think we've come up with a design yet, and we welcome the community proposing one (using our Proposal process).
jmg-duarte commentedon Apr 5, 2024
I'm doing a client though, would that work?
czechboy0 commentedon Apr 5, 2024
Apologies, I took the above to mean you're writing the server. Yes, just replace
ServerMiddlewarewithClientMiddleware, and use this example instead: https://github.com/apple/swift-openapi-generator/tree/main/Examples/auth-client-middleware-exampleczechboy0 commentedon Oct 29, 2024
Related to #37.
laconicman commentedon Apr 7, 2025
Perhaps this piece of code modesty named
RefreshTokenAuthMiddlewaremight be useful to you. It's not OAuth2, but it's a refresh token authentication scenario. You might be able to reuse some of the approaches.I'm no expert on Modern Concurrency, but I've tried to make use of it.
huven commentedon Jun 25, 2025
Is it supported to call next() more than once inside intercept()?
If the server responds with 401, the middleware can obtain a new access token using the refresh token, and then retry the request before returning the response, all without bothering the caller. I'd rather not wrap all API calls with that logic.
I know the client could do that periodically before expiration and pass the new token to the middleware, but there might be other reasons for the server to return 401.
This could be used for resiliency too.
czechboy0 commentedon Jun 25, 2025
Yes in a middleware, it's allowed to call next() multiple times, exactly for this use case, like retries.
The only time when it won't work is if you're doing request streaming using a single-iteration HTTPBody. But otherwise will work.