-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for different grant types #54
Comments
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. |
Hey @Trojan295 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. |
There's some confusion about OIDC and OAuth 2.0 in this thread and #46. 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. |
I would like to avoid adding RO Password Credential grant. It's not recommended and I don't see any advantage of having it. @novacp, are you OK to close this? |
Closing, feature not accepted |
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. |
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 :-)
The text was updated successfully, but these errors were encountered: