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
Given that OAuth2 and JWT access tokens are widely used and adopted, I'd like to use tokens to protect nuclio functions which expose some kind of API. While OAuth2 is currently supported, this is done via a proxy, which will trigger an interactive authentication flow.
This is incompatible with APIs consumed by clients, which can not interact with users to perform the auth flow. OAuth2 access tokens, mostly in the JWT format, are widely used to protect API ("resource servers").
Feature Description
The support for JWT Authentication can easily be added by integrating an authentication helper for the nginx ingress controller, which will validate the JWT and resolve the authorization via the same scheme already adopted for oauth2.
On the controller side, config can be generated by adding annotations to the Ingress creation, pointing the auth-url to the pre-configured authentication helper.
An additional AuthenticationMode could be added to the CR, similar to the following, which will specify the audience required for the given resource.
An alternative solution, when the scenario requires the usage of JWT tokens, is to drop the apigateway and either:
manually write the Ingress definition with all the annotations
migrate to another (generic) apigw solution.
Additional Context
Given that this feature is relevant for our use cases, I've already implemented the feature in our fork.
If you guys think this is valuable I can open a pull request to contribute it back.
The text was updated successfully, but these errors were encountered:
Feature Type
Adding new functionality to Nuclio
Changing existing functionality in Nuclio
Removing existing functionality in Nuclio
Problem Description
Api gateway currently can expose nuclio functions by writing an Ingress with optional authentication.
Authentication modes (from code) are:
Given that OAuth2 and JWT access tokens are widely used and adopted, I'd like to use tokens to protect nuclio functions which expose some kind of API. While OAuth2 is currently supported, this is done via a proxy, which will trigger an interactive authentication flow.
This is incompatible with APIs consumed by clients, which can not interact with users to perform the auth flow. OAuth2 access tokens, mostly in the JWT format, are widely used to protect API ("resource servers").
Feature Description
The support for JWT Authentication can easily be added by integrating an authentication helper for the nginx ingress controller, which will validate the JWT and resolve the authorization via the same scheme already adopted for
oauth2
.On the controller side, config can be generated by adding annotations to the Ingress creation, pointing the auth-url to the pre-configured authentication helper.
An additional AuthenticationMode could be added to the CR, similar to the following, which will specify the audience required for the given resource.
Also for ingress types
And then eventually wire things while building the ingress definition.
Alternative Solutions
An alternative solution, when the scenario requires the usage of JWT tokens, is to drop the apigateway and either:
Additional Context
Given that this feature is relevant for our use cases, I've already implemented the feature in our fork.
If you guys think this is valuable I can open a pull request to contribute it back.
The text was updated successfully, but these errors were encountered: