Using Kong with existing OAuth2 provider

[andrew.pa...@gmail.com]

Is it possible to use Kong to authenticate bearer tokens generated by our existing OAuth2 compliant solution, or am I required to switch to using the Kong implementation?

Any pointers to documentations or discussions about this would be super helpful.

Thank you!

[Marco]

There is an open issue to implement an OpenID connect integration. We are planning to build it but we currently have no definitive roadmap. PR's are welcome :)

 Marco Palladino | CTO @ Mashape | mashape.com | +1 (415) 361-3858

--
You received this message because you are subscribed to the Google Groups "Kong" group.
To unsubscribe from this group and stop receiving emails from it, send an email to konglayer+unsubscribe@googlegroups.com.
To post to this group, send email to kong...@googlegroups.com.
Visit this group at https://groups.google.com/group/konglayer.
To view this discussion on the web visit https://groups.google.com/d/msgid/konglayer/2ce2fd37-fc14-4d90-88b1-c5c869e06c73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luiz Omori]

+1, it would be great to have a standard plugin for that.

We ended up coding our own very simple which basically just checks for the Authorization Bearer token and if not cached does an Introspection against the OAuth AS to validate it (we handle the access token as opaque). Once validated the Introspection result is injected into a X-Introspection header so the actual Resource Server (RS) can access it. The RS does have an IP table (whitelist) to validate that indeed requests with such X-Introspection header are coming from Kong's plugin.

One complication particular to us is that some RSes (legacy, can't change the code) may need specific custom headers derived from the Introspection so may still need a custom plugin after the generic one. :(

Note that we didn't put the OAuth AS behind Kong so our clients exercise the normal OAuth protocol to obtain the access token, our plugin just validates the incoming requests. I wonder now if from the plugin perspective it would be advantageous to have the AS behind Kong. Oh, maybe it could cache the AS provided tokens so it doesn't have validate it later.... Introspection??

Regards,

Luiz

[Martin Danielsson]

If you are using JWT signed tokens, this ought to work out of the box, having Kong checking the signature using the jwt plugin (you will need to share the secret). If you have opaque tokens, this is not so easy...

/Martin

[Luiz Omori]

Yeah, signature verification by using the issuer's public key (no shared secret per se) is one way but we moved away from it when started facing encrypted tokens, which is a bit easier as we could at least retrieve the issuer (we have multiple OAuth servers internally) and introspect according, but opaque for everything else.

Regards,

Luiz