Skip to content
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

Private Key JWT or howto authn to API backend? #1048

Open
s0l4r opened this issue Feb 10, 2023 · 1 comment
Open

Private Key JWT or howto authn to API backend? #1048

s0l4r opened this issue Feb 10, 2023 · 1 comment

Comments

@s0l4r
Copy link

s0l4r commented Feb 10, 2023

Hello,

I am trying to integrate our private backend API (FastAPI) with Kusk Gateway with Zitadel, but I haven't been able to make it work.

Are there any plans to support Private Key JWT in Kusk Gateway, so that it could be used between Kusk API Gateway and a backend API (machine to machine) ? Or is it already supported, but I don't understand how it works?

See:
https://oauth.net/private-key-jwt/
https://www.rfc-editor.org/rfc/rfc7523
https://cloudentity.com/developers/basics/oauth-client-authentication/private-key-jwt-client-authentication/
https://developer.okta.com/docs/guides/build-self-signed-jwt/java/main/#build-a-jwt-with-a-private-key

It is different from client_secret authentication, see:
https://oauth.net/2/client-authentication/

Using Private Key is the recommended authn method for API's in Zitadel:
https://zitadel.com/docs/apis/openidoauth/authn-methods#jwt-with-private-key
https://zitadel.com/docs/guides/manage/console/applications#api

In this scenario, no client_secret is entered but an RSA private key that the JWT is signed with in my understanding.

So far in Kusk, I cannot see an option to provide a private key in the configuration for JWT.

The required steps to get this working is:

  • The client is registered with the private_key_jwt method as the token authentication method.
  • A public and a private key pair set is prepared on the client-side.
  • The client’s public key is converted from the PEM format to a jwks (JSON Web Key Set)

As we are using an SPA (Single Page Application), we don't want to store the client_secret on the client side, so my thought was that the clients use Authorization Code with PKCE flow, and for all API requests made by the client to Kusk Gateway. Then use a private key machine to machine between Kusk Gateway and in our case Zitadel for the API authn.

I will attach a diagram (which is somewhat incomplete and might have missed a few steps. I am sure it's incorrect too, but for now I am trying different flows to get it working. This is how I vision it to work at the moment:

Screenshot 2023-02-10 at 14 39 50

My issue is with step 7,8,9 at the moment, where my private API is not authenticated at all, but the Kusk Gateway does (either using private key or client_secret), forwards the request to the backend, and the backend returns the data to the user.

If anyone has any experience using Kusk Gateway and Zitadel, or is willing to try it out, I would be very happy to hear your comments!

Thanks!

@aabedraba
Copy link
Contributor

Thanks for opening the issue @s0l4r !

We currently don't support private key with the JWT extension. We were actually thinking of adding it.

To unblock you, I believe you'll find the Custom Auth Upstream helpful to solve this problem. Basically, it allows you to write an auth service in whichever language you want and have it integrated with Kusk Gateway. That way, you can really achieve maximum customization with the way you setup auth.

I actually added a Firebase JWT authN example today that could be helpful to look at: https://github.com/kubeshop/kusk-examples/tree/main/with-firebase

Let me know if this solves your problem!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants