nokia / kong-oidc

OIDC plugin for Kong
Apache License 2.0
454 stars 321 forks source link

The original token is not passed to resource server #44

Closed shlomiken closed 5 years ago

shlomiken commented 6 years ago

Hi first of all , good job this is exactly what i was looking for in an API gateway functionality. my question is , the description of the project say that it is up to the resource server to verify the token but the token is not passed (according to docs only) to the resource server only the X-UserInfo header with the claims.

should we just trust the plugin for verifying the JWT token. thanks Shlomi

Trojan295 commented 6 years ago

Hello, You're right, the JWT is verified on the plugin side and only the claims are put to X-Userinfo headers, so you cannot verify the token in the upstream application. This means, that you need to protect your application from malicious requests (ie. someone could bypass Kong and send a request directly to you application with a modified X-Userinfo header.

shlomiken commented 6 years ago

if so , then where is the configuration for HMAC secret or RSI public key to verify the JWT token ?

Trojan295 commented 6 years ago

Only asymmetric signatures are supported. You don't have to put the public key, cause it's fetched from the authorization server from the OIDC Discovery Document (jwks_uri field) For ex. (from Google) https://accounts.google.com/.well-known/openid-configuration https://www.googleapis.com/oauth2/v3/certs

shlomiken commented 6 years ago

great thanks.

shlomiken commented 6 years ago

can we add this as a requirement - so we can enforce more security on resource server instead of trust of network ?

androa commented 6 years ago

It would also be nice to have the token in order to propegate the identity down to backing resource servers.

Trojan295 commented 6 years ago

@shlomiken, you mean to add an option to set the public key explicitly in the plugin configuration?

The discovery document is served by the OIDC provider. It's a bit strange, if you cannot trust it, cause then any authentication done with the provider is untrusted.

shlomiken commented 6 years ago

@Trojan295 no , its ok to go to OIDC provider (as long as you somehow cache it) i think the token needs to be passed to upstream services , for them to be able to verify as well. also be able to look at custom claims the OIDC provider might add to the token.

pavel-mikhalchuk commented 5 years ago

Hi @Trojan295,

Could you please take a look at my commit - https://github.com/pavel-mikhalchuk/kong-oidc/commit/b4976fc0e37c907cf01a5ed1db1ff29573b449d8 - and let me know if this is kind of the code you're expecting? I'd be glad to help you with this issue since my current need is to make your plugin pass access token to upstream resources.

Thanks!

Trojan295 commented 5 years ago

@pavel-mikhalchuk, I need to test it out, but looks ok. Send a PR and I will check it. :)

pavel-mikhalchuk commented 5 years ago

Here you go https://github.com/nokia/kong-oidc/pull/75. I'm gonna add some unit tests for this later.

Trojan295 commented 5 years ago

Closing, because of #75 merge