Request for "secret storing" or "env vars"

[soft raptor]

Like many hosting platforms (e.g. Vercel have, I think it would make sense for Appsmith to have a "secret" store, where you can keep your API keys, etc), all of these would be encrypted, and hidden from the UI after creation. This way you could then reference them like {{ appsmith.secrets.AWS_KEY }} or something.

Thanks for all the nice work on Appsmith!

[azure yarrow]

@soft raptor could you elaborate on the type of secrets you're looking to store? Today we store the secrets such as the AWS API key in the API/DB datasource. It is encrypted and not returned to the client

[soft raptor]

Of course!

We are using Auth0 for auth, as custom authentication, like described here: https://docs.appsmith.com/advanced-concepts/how-to-implement-custom-authentication-on-appsmith

This means that we use an API to get a token and store it client side using storeValue.

But to do this, we have to store the Auth0 client secret as plaintext inside the datasource. It is true that this never touches the client, but it does touch your servers as plain text, and, most importantly for us, it touches our Git repo (synced) as plain text.

We would want a way to minimize this surface area by storing this secret encrypted. Eventually we will move to self-hosted (paid) version which will be even better, but having this secret "in the middle" of the app feels like a security flaw.

Does this make sense?

Thanks again for all the work!

On another watch, I see that Confidence doesn't (in the Google/Xano tutorial) have a secret anywhere inside Appsmith, which seems weird to me ahah

Should I be using the PKCE version, which doesn't need the secret to be present anywhere on the application side, not even the server?

As a sidenote: I understand that I can use authenticated datasources to hide my secret as much as possible, but (in addition to not being able to get it working) it seems like a weird setup, since I want to login first, then store a secret on the client and not authenticate on every request I make to the API.

I assume the authenticated datasource has to go to the auth provider (in this case, Auth0) every time, since it is not storing the token/JWT anywhere on the client?

[azure yarrow]

@soft raptor did you use the OAuth 2.0 authentication type in the API datasource or did you hardcode the secret in the headers? If you did the former, then it should definitely not sync it to git and be encrypted. It you did the latter, that could cause this but is there a reason you are hardcoding it in the headers and not using the authentication type?

[soft raptor]

Appsmith devs have Dev access to our app (asked for here #1064962993793806336 message) so you can investigate exactly what's going on.

But as a brief explanation: we have the secret hardcoded in the body of the request, as necessary per these docs (https://auth0.com/docs/api/authentication?http#authorization-code-flow44)

This is because the person will login with Google, we call these endpoints and store a JWT client side. Then just use that token to call our API (using {{ appsmith.store.jwt }} on the header of each API call.

What I'm maybe realizing is that our whole flow is wrong, at a high level.

To summarize, we do:

1. Person goes to Appsmith app (has to be invited of course)
2. Nothing is shown by default, but there's a Sign In button
3. Person clicks, and gets directed to Auth0/Google login, using Auth0's /authorize endpoint. This returns a code (via URL param)
4. Person gets redirected to a "Success" page, where we use the /oauth/token endpoint to exchange the code for a token (this requires the secret to be sent in the request body, and this is the endpoint where the secret is exposed on Appsmith)
5. We get, in the response, a temporary JWT token, which we store with storeValue
6. To call our internal APIs, we use {{ appsmith.store.jwt }} in the headers. This is because (as you may deduce) our internal API checks for the validity and scopes of this token provided by Auth0.
7. We then check for the existence of this JWT to show tables, etc

I hope this helps. And sorry for taking so much of your time @azure yarrow (tagging because you tagged and maybe it helps organize, idk 😅)

[dusk radish]

Thank you for sharing the details. Our team needs some time to investigate this
and will get back to you.

[soft raptor]

Thank you!!

[tribal drum]

Hi I think I understand what you want to achieve, I think OAuth 2.0 is what you need you can follow this setup guide what it does is get the token from Google auth and keeps it encrypted to authenticate your data source you can follow this guide as an example, if this isn't helpful or isn't what I'm looking for, please let me know.

https://docs.appsmith.com/core-concepts/connecting-to-data-sources/authentication/authentication-type/oauth2-authentication

[soft raptor]

Hey! This is not super useful for the reason outlined above, let me try to get it:

"As a sidenote: I understand that I can use authenticated datasources to hide my secret as much as possible, but (in addition to not being able to get it working) it seems like a weird setup, since I want to login first, then store a secret on the client and not authenticate on every request I make to the API.

I assume the authenticated datasource has to go to the auth provider (in this case, Auth0) every time, since it is not storing the token/JWT anywhere on the client?"

Either way, I cannot make this work, since when I try to authenticate, I'm redirected to a 404 page, and I have no access to any meaningful logs to try to debug 😦