I’ve made a simple tool which I want to connect Stripe too and a database for user specific content, while using Memberships for the login, to eventually load the user specific content on for instance the user’s account page. I’ve researched some once more, and what’s stopping me from continuing is the in browser visible Alternative User ID, which could be changed if someone’s willing to and so could access other user’s content.
I know however a bit my way around serverless/cloud functions.
Would there be any way of accessing the Alternative User ID, -or Memberships User ID-, without making it accessible in the browser? Because I think this would solve my problem, since I would then be able to authenticate the user in a cloud function(?).
The user specific content isn’t that sensitive, but I just don’t like the fact that it would be possible when you paid for something.
The Alt User ID is generated client side and it’s calculated as a one-way hash of the only persistent and user-unique identifier we have access to, which is the user’s email. We use it when we need to identify the user in another system, but do not want to pass PII around.
You don’t need to explicitly make the Alt ID visible, but yes if someone knows what they’re doing, they can access the Alt ID of the currently logged in user if they have access to that machine. It would be very difficult to guess the Alt User ID of another user, but it’s easy enough to recreate if you know their email.
In short, I wouldn’t use it as a security mechanism.
If I know how your system works, and I know you are a user, and I know your email, I can create that Alt ID and use it as a “ticket” to access your APIs. There are a lot of “IF’s” there, so you have to decide if that provides a suitable level of security for your use case.
In house-security terms, it’s the tall chain-linked fence, but no barbed wire at the top.
Thanks again for your in depth information and sorry for my late reply(!). I’ve started investigating alternatives because I can’t take the risk, potentially financially.
From a security approach “hiding” those ID’s wouldn’t actually give you any real security. I think your best bet is probably to look in the direction of-
Wized, or possibly Memberstack, for the SSO piece
Use SSO to authenticate the user securely against a proper auth framework, including MFA, etc.
Then use that same SSO to access your data on a 3rd party secure repository.
Notice I didn’t mention Webflow pretty much anywhere here. Memberships is not a security platform at all, and any content you deploy on Webflow ( including gated content ) really won’t be “securable”.
You can use Webflow as the front end all the way up to the secure areas, and then stop there.
