we would like to use an external OAuth 2.0 Identity Provider (IDP) for federated authentication - in principle, a similar feature to this one of WSO2 IS:
Basically, we would like Kong to be responsible for issuing the actual end-application OAuth 2.0 access token (and doing all associated API management stuff), and only use the external IDP for handling the actual user authentication. The external IDP has own OAuth 2.0 Authorization service (and can issue “internal access token”, not used by end-application, but only internally between Kong and IDP) and provides one secured resource for obtaining more user information (so that Kong knows to which user to issue an actual access token).
Does anyone have some experience with this setup?
With kind regards,
You can certainly do that as a custom plugin. There are some 3rd party plugins, e.g. this:
That you could use with, e.g. this (EE only):
Or (3rd party, OSS):
Excellent - thank you, the plugin by Nokia looks very promising.
Another Plugin I have used that implements OIDC - it needs a little work for working with the latest versions of Kong (swap out the lua crypto for newer lua ossl), its what we are using internally but we have not released the modified source code publicly but may in the future -
Also looks nice - I like how minimalis it is. We would have to fix it a little bit so that access tokens are actually issued by Kong, not the 3rd party IDP… but this should not be too hard. Thank you.
Hi @PetrDvorak, @bungle, @jeremyjpj0916, @thefosk,
I have a similar use case that you have implemented with custom auth service. Main Idea is that we cannot share the client credentials with external service and cannot share the authenticated JWT with client.
When the client tries to authenticate by presenting the client Id and secret(Basic Auth), I want to route the request to custom authentication service. We have the client information saved in our database and is segregated to different realms(user groups). Implemented an auth-service that validates the client credentials based on the realm and generates a JWT response. JWT has sensitive information so cannot be shared with the client. This auth-service has multiple versions, so we need to route the request to different auth-service endpoints based on the realm(sent in the query parameter) and a custom header.
Once the auth-service returns a JWT response, Kong should be able to generate an oauth token and save the associated JWT in cache. This OAuth token will be shared with the client. When client presents this token in the Authorization header, API Gateway should be able to validate the token and get the JWT that was saved before and inject into to the backend request.
Does Kong support any plugin for this set up, Could you please share the relevant links?