GitHub user ypandey-fluidata created a discussion: Secure Multi-tenant Guest Token Exchange for No-Code Frontends
### Bug description We are implementing superset-embedded-sdk within a multi-tenant application where the frontend is a no-code platform (Softr). The application serves data from a PostgreSQL warehouse with strict Row-Level Security (RLS) requirements. Current Implementation (Insecure) Currently, the client-side JS fetches a Guest Token by passing the user’s email directly to a backend endpoint. fetchGuestToken: () => fetch(`https://api.test.co/get-token?email=${window.logged_in_user.email}`) --This is susceptible to ID Spoofing. Since the frontend JS is public, a user can modify the email variable in the console to request a Guest Token scoped to a different tenant’s RLS rules. The Proposed "Zero-Trust" Architecture We are moving to a token-based exchange to eliminate PII and spoofing. We would appreciate feedback from the maintainers on the security of this flow: 1. Token Generation: Upon user login, our backend generates a unique, random App_Session_Hash (stored in Postgres, mapped to the user). 2. Frontend Handshake: Softr passes only this hash to our Middle-man API. 3. Backend Validation: - The API validates the App_Session_Hash against the DB. - It retrieves the associated rls_clause (e.g., client_id = 501) directly from Postgres. - Superset API Call: The API calls the Superset /api/v1/security/guest_token/ endpoint (Server-to-Server) using the rls_clause retrieved from the DB. - Scoped Delivery: The Guest Token is returned to the frontend. #Specific Questions for Apache Superset Devs: 1. Guest Token Over-scoping: Is there a risk of "Token Hijacking" if the guest_token is intercepted? Does the SDK provide a way to bind the token to a specific client IP or browser session beyond the exp (expiration) claim? 2. CSRF in Embedded Context: When the SDK performs the fetch for the dashboard assets using the Guest Token, how can we ensure that the fetchGuestToken call itself is shielded from CSRF attacks given that we cannot easily set custom HttpOnly cookies in a no-code frontend? 3. SDK Caching: Does the embedded-sdk have a native way to handle token refresh before expiration without a full page reload, or should we implement a recursive setTimeout logic within the fetchGuestToken function? Environment: Superset Version: 6.0 ### Screenshots/recordings _No response_ ### Superset version master / latest-dev ### Python version 3.9 ### Node version 16 ### Browser Chrome ### Additional context _No response_ ### Checklist - [x] I have searched Superset docs and Slack and didn't find a solution to my problem. - [x] I have searched the GitHub issue tracker and didn't find a similar bug report. - [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section. GitHub link: https://github.com/apache/superset/discussions/38404 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
