Support for different grant types

[novacp]

As far as I read, the plugin is using the AuthorizationGrant type. Does it also support using implicit and password grant type within the RP/Client/Kong+this plugin? When it comes to using OAuth/OIDC as SSO within my own, first party microservice project, I need to be able to integrate different grant types, while having Kong act as the RP/Client for my Authorization server, e.g. Keycloak.

Best regards ++
p.s I am well aware of how to use OAuth/OIDC, especially as a SSO solution for first party applications :-)

[Trojan295]

So the Password Grant support would be, that the plugin exposes an endpoint, where you can send the username and password, and the plugin would exchange them for the access token and use like in the Authorization Code grant?

Could you elaborate more, how the support for Implicit grant could look like? AFAIK, the access token in this flow is put in the fragment identifier, so Kong wouldn't get it in the URL.

[novacp]

Hey @Trojan295
The first statement is completly right - in the end, the API-Gateway (Kong) with the help of the plugin (kong-oidc) would intercept the request of the client, e.g. a first party reactjs spa.
The client therefore sends a request to Kong, e.g. POST /login, including its username and password. Kong (plugin) intercepts and creates its own password grant request to the OAuth/Openid-Connect Authorization server. Therefore, we need an endpoint at kong, provided by the plugin, that intercepts the request and creates a password grant one, returning the tokens (access token, refresh and id token) as cookies back to the client. Refreshing etc. is done like with the Authorization grant.
(Now you might think about client impersonation .. well there is no real protection against client impersonation - not at all when it comes to public clients and also not even if there is a backend with a secret requesting, because as an attacker, you could always make a "roundtrip to the real backend" and intercept requests, but this is a different story.)

To implicit grant: this isn't needed at all, because if you use OAuth as you should (third party), authorization code is the right way to go for a backend like kong. But if you use OAuth as SSO in first party app, you would need the "Api-Gateway-intercept-request-create-own-password-grant-request" approach :-). Sorry for confusion with implicit grant.

[zandbelt]

There's some confusion about OIDC and OAuth 2.0 in this thread and #46.
For OIDC It does not make sense for the Kong/resty-openidc plugins to support anything other than Authorization Code.

The plugins can also work as an OAuth 2.0 Resource Server, validating access tokens but in that case the SPA is better off to be a public client on its own to obtain the token.
without involving Kong/resty-openidc, using the Resource Owner Password Credentials grant against the Authorization Server or Implicit. That's how the standard envisoned it.

[Trojan295]

I would like to avoid adding RO Password Credential grant. It's not recommended and I don't see any advantage of having it.
And other grant types don't make sense on Kong.

@novacp, are you OK to close this?

[Trojan295]

Closing, feature not accepted

[mssaisandeep]

I know that this ticket is closed. But I would like to understand a few things:

As kong official (enterprise) supports all different flows(grants), what is the issue in avoid adding a password credentials grant which is worth adding into this plugin? So this kong-plugin can be used for cli-based clients as well as browser-based clients.

Will there be any issues, if we add that into this plugin. Just I would like to understand more about it. Please help me.

Can someone provide me at least theoretically how can we implement this?

Once again sorry for reopening this thread. Because I feel this plugin is so good and worth it if we can extend by adding more flows.

@Trojan295 Let me know your thoughts on issues that we may see if we implement.