Our project walletchat has a chat widget option, utilizes iframes for use in web3 apps like peer to peer lending. currently users may have to sign in twice - once for the main app, and again via the iframe since its a separate domain. asking for advice best practices around securely sharing a JWT token between two sites to make it easy and secure to sign in. @avi
You can serialize the session: Managing Sessions | Decentralized Identifiers (DIDs)
As long as you have a secure way of transmitting the serialized session between your two domains there shouldn’t be a problem with doing so. Avoid sending the serialized session to any server though!
1 Like
Well, therein lies the issue, unless I am just not understanding it right.
lets saying forum.ceramic.network implements our chat widget, which points to ceramic.walletchat.fun.
- User logs into Ceramic forum with their wallet/DID/SIWE type login, and the DID or JWT is returned in local storage.
- User wants to log into WalletChat, ideally they are auto-logged in (reason to share the login token)
We can have an API endpoint where the Ceramic forum integration sends us a valid login token, but how do we prove that user wanting to login to WalletChat, really owns that wallet without them having to sign something? It seems to me the same security flow would need to happen to grab the Ceramic forum token, as it would to just perform a normal login.
Hopefully that makes sense?
I was thinking of using PostMessage with strict domain allow-listing, but wasn’t 100% sure this was fully secure.
Modern browsers usually provide good cross-origin security primitives, but you should make sure your logic leverages them, see Window.postMessage() - Web APIs | MDN for example to check the communication between the iframe and host window happens between the expected domains.