Dynamic Parameters For .env and inputs

[Jonneal3]

Quick question guys... When we get towards the final step which is actually running the API upon execution, there are "use case inputs" and parameters that I need to be able to populate correctly to run the API's.

What is the common best practice to managing which ones are required of those inputs? For example, in the "resend" email documentation example, the "to" and "from" email are required. But, we need to know that they are required to input. Is this just something that I will have to track manually and store the required inputs on my own?

Lastly, because I am weaving all of this into my app, and my users add their own Oauth Credentials, how do you recommend I manage the oauth credentials in terms of environment variables for many users and many softwares? What is best practice here?

Thanks!

Jon

[martyndavies]

Hey @Jonneal3, thanks for the question.

Right now, this is something that you'd need to track manually, storing which required inputs are needed on your side. However, it's a great ask, and it got us thinking about the modifications we could make here to help with that.

For OAuth, because your users would be authenticating your app with the service they want to use, you'll need to ensure that the resulting OAuth Access Tokens you get from that process are stored securely. You will use those tokens to make requests via Superface's OneSDK, but Superface doesn't need to be part of the OAuth process.

There's lots of guidance around about how to work with use OAuth credentials safely, and this guide from Square stood out to me with some good advice.

[Jonneal3]

Hey Martyn! Got it thanks! I guess what I meant by the Oauth process was that, in the tutorials i've watched, it sounds like we have to add tokens or api keys for each software/provider we intend to use, specifically, in .env. What I was wondering was, how would I do this for users? For example, if I have many users with "google calendar oauth" credentials in the .env for example, how is the execute command going to know which credentials to use for each key in the .env file, if I have say 100 different "google tokens" in the .env? Hence, I was wondering if there is a way to attach other variables or parameters to each key in the .env to be able to distinguish. Thanks! Jon

…

On Thu, Aug 10, 2023 at 10:18 AM Martyn Davies ***@***.***> wrote: Hey @Jonneal3 <https://github.com/Jonneal3>, thanks for the question. Right now, this is something that you'd need to track manually, storing which required inputs are needed on your side. However, it's a great ask, and it got us thinking about the modifications we could make here to help with that. For OAuth, because your users would be authenticating *your* app with the service they want to use, you'll need to ensure that the resulting OAuth Access Tokens you get from that process are stored securely. You will use those tokens to make requests via Superface's OneSDK, but Superface doesn't need to be part of the OAuth process. There's lots of guidance around about how to work with use OAuth credentials safely, and this guide from Square <https://developer.squareup.com/docs/oauth-api/best-practices> stood out to me with some good advice. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWFFE6SVZ2FEH4IIGEH7Q2LXUT3VHANCNFSM6AAAAAA3KLHWFY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[martyndavies]

In our examples, .env is fine for storing credentials because it's a small implementation of a single key for a single service, which is fine when it's your own key. However, I wouldn't recommend the same approach for a production application that will work with many different authentication tokens on behalf of your users.

At scale, you would want to design a more robust system for storing those credentials.

As per your question, if you have 100 users that want to authenticate Google Calendar, you _wouldn't_store all of those in an .env file for security reasons but also for ease of access. Rather, you would need to design your database to securely store an authentication token in a properly encrypted manner for each service a user adds to their account with you.

Then, when it comes time to make a request on behalf of that user to a service using OneSDK, you would grab the authentication token from your DB, decrypt it, and use it to make the request.

I would encourage you to consider your database design early on to ensure you follow good security best practices from the start.

Hope this helps!

[Jonneal3]

Ahhh ok got it! Cool! I already have an encrypted way of storing the users credentials in my own database, and was just wondering about best practice for making the request to superface. My skills lack a bit when it comes down to production servers and creating the endpoints themselves, but that makes sense now! Will look into implementing this and let you know. Thanks again for the help! Jon

…

On Fri, Aug 11, 2023 at 10:45 AM Martyn Davies ***@***.***> wrote: In our examples, .env is fine for storing credentials because it's a small implementation of a single key for a single service, which is fine when it's your own key. However, I wouldn't recommend the same approach for a production application that will work with many different authentication tokens on behalf of your users. At scale, you would want to design a more robust system for storing those credentials. As per your question, if you have 100 users that want to authenticate Google Calendar, you _wouldn't_store all of those in an .env file for security reasons but also for ease of access. Rather, you would need to design your database to securely store an authentication token in a properly encrypted manner for each service a user adds to their account with you. Then, when it comes time to make a request on behalf of that user to a service using OneSDK, you would grab the authentication token from your DB, decrypt it, and use it to make the request. I would encourage you to consider your database design early on to ensure you follow good security best practices from the start. Hope this helps! — Reply to this email directly, view it on GitHub <#10 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWFFE6STCGUL2TLAVXN6SV3XUZHS7ANCNFSM6AAAAAA3KLHWFY> . You are receiving this because you were mentioned.Message ID: ***@***.***>