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
The current implementation makes the assumption that the authorization code flow is in use.
My feature request is integrating OAuth2 client-credentials flow to achieve machine-to-machine communications. The idea would be to replicate what has already been done for OIDC: standard implementation, caching features shared across HA NGINX instances (please, see the end of this description) and suggested advanced NGINX settings out of the box. This means having a standardized implementation of RFC6749 for the above-mentioned grant-type (i.e. client-credentials), where NGINX Plus is configured as a relying party.
In the given scenario, the use-case is therefore the following:
The client_id and client_secret are inserted by the client application in the request payload and submitted to NGINX for the purposes of requesting a new access token. Caching of the access token is done by the application itself, which requires NGINX to issue a new token when the old one expires in the application internal cache. Either way, NGINX might cache the access token too if you deem it necessary.
The text was updated successfully, but these errors were encountered:
The current implementation makes the assumption that the authorization code flow is in use.
My feature request is integrating OAuth2 client-credentials flow to achieve machine-to-machine communications. The idea would be to replicate what has already been done for OIDC: standard implementation, caching features shared across HA NGINX instances (please, see the end of this description) and suggested advanced NGINX settings out of the box. This means having a standardized implementation of RFC6749 for the above-mentioned grant-type (i.e. client-credentials), where NGINX Plus is configured as a relying party.
In the given scenario, the use-case is therefore the following:
The client_id and client_secret are inserted by the client application in the request payload and submitted to NGINX for the purposes of requesting a new access token. Caching of the access token is done by the application itself, which requires NGINX to issue a new token when the old one expires in the application internal cache. Either way, NGINX might cache the access token too if you deem it necessary.
The text was updated successfully, but these errors were encountered: