LNTWOOL - Buildships doc's are in dire need of ...
Buildships doc's are in dire need of updating. This should be documented. I need to know - if i set a workflow variable, which is basically a transient authentication token, that is unique to each user. When i capture and store the token in the workflow variable, and user 2 hits the api seconds later, is it user 2 token that is stored, thus breaking user 1 not to mention security, now user one see's user 2 information. There is zero information about session state. a user is not using the api for longer than 5 minutes max, so i reaally hope i don't hear an answer of "build out a storage layer"
4 Replies
Hi @LNTWOOL, storing an authentication token in a workflow variable isn't ideal. We recommend you to use keys or secrets. Which will remain encrypted within BuildShip and won't be accessible to users.
Also, we working on updting docs, we'll update all the v2 resources on docs by this month.
I agree - such short lived tokens commiting them to a secrets store seemed be alot of overhead. so if i have 300 users, it's not an issue to us
built in secret store?
okay, for this case, use the authorization header to send tokens no need to store https://docs.buildship.com/tutorials/secure-api
Secure Your API Endpoint – BuildShip
A unified resource to start building your backend with low-code. Dive into triggers, nodes, and step-by-step guidance to jumpstart your workflow creation.
Sorry, didn't read through your response... -- To be clear, Authenticated user flow: Client -> AI Agent (not in Build Ship) -> 4 or 5 outbound (outside of Build Ship) API Calls that happen over a roughly 5 minute period that must include bearer token -> AI agent -> Client. -- Authentication Flow: AI Agent (not in build ship) on behalf of the user -> Sends outbound API request to Twilio for the dual auth short code -> The user types dual auth code the user receives via SMS into agent -> Agent verifies by -> another API request to Twilio -> If code is good, the token in question here, a bearer token is returned. So i am not securing my Build Ship API's, I am making outbound API calls to get authenticated for the subsequent API call's from build ship nodes -> to API's outside of build then talk to other API's via Build Ship. My questions has been around sessions concurrency and isolation, but no one has been able to answer the question. So if that question cannot be answered, is there any unique session based, environment variables that maybe i can use to store the variables in a consistant but unique way. The client itself does not do the authentication, thus nothing is sent to Build Ship, thus i have to store it because I'm not storing it on an AI agent. I would this this use case can't be that unique, take the agent out of the equation, for a production API i would think you have a framework around this
Sorry, did not type correctly. Authenticated user flow: Client -> AI Agent (not in Build Ship) TO BUILDSHIP API's-> BUILDSHIP API's make 4 or 5 outbound (outside of Build Ship) API Calls to a scheduling system, that happen over a roughly 5 minute period that must include bearer token -> Scheduling system API's -> back to Buildship Nodes -> return to AI agent ->AI agent presents to Client