I wanted to pile on a little bit here and say this paragraph isn't really comforting to me:
> While unlikely to happen, it is possible for a savvy user to open their browser's developer console, obtain your MagicBell project's API key from your website's source, initialize the widget on their own website with your API key but with a different user's email (if its feasible for them to guess one) and start viewing notifications of that user.
I suspect this was done for developer experience reasons? You seem to know it's not secure to pass in an email directly, especially if anything sensitive is coming across in notifications.
For me at least, allowing the non-HMAC configuration makes me wonder what other security corners have been cut. I'd rather that option didn't exist and the company took a more security-forward stance.
Edited the doc to remove the bit about this scenario being unlikely. We take security very seriously and would be happy to get feedback on the new copy (or any other aspect of MagicBell).
I see your point with Intercom, but it feels like you're arguing that two wrongs make a right. It doesn't make me think MagicBell takes security very seriously, but perhaps I'm just paranoid.
Regardless, the copy on the website is improved. You may also want to add a warning and link anywhere your website documents the "userEmail" option.
On another note, in terms of the implementation here, I'm surprised you're asking users to use HMAC and base64 manually, instead of using standardized JWTs. Did anything in particular motivate that decision?
I quite like the product overall - I think it's very clever how you componentized everything. The security decisions just have me concerned.
Hi thrwaway2020aug, indeed we could have made a better choice in that regard. Actually we plan to move to JWT in the coming months.
Be asured that we take security very seriously. We are in conversations with banking platforms, and with that in view, we are planning to get a SOC 2 certification very soon.
I agree that this can be worded better and we will certainly do so. Thank you for your feedback. It's fairly common to see this pattern of HMAC off by default (ex: Intercom) to help people test their embed. Atleast at the moment we are in touch with everyone going live and make sure this is communicated to them (doing things that don't scale).
The ski boot industry has been focused on reducing plastic weight / thickness while remaining sturdy. People very much appreciate the innovations there.
The reason I ask is because Cloudflare's "orange cloud" DNS mitigates that protection because it prevents Safari from detecting the cloak. On the other hand, I haven't run into many engineers who think CNAME-cloaking actually hurts privacy in light of Safari's other efforts to partition local storage.
Does Cloudflare think it would be help privacy for Apple to know the final IPs behind orange cloud DNS?
If I understand correctly, you're having me integrate a library on my backend that manages session cookies.
You've implemented refresh tokens and that seems to be one of your major selling points, but I'm confused what benefit that provides?
I thought the use case for refresh tokens in OAuth was that the user can revoke access from the OAuth provider side. But since the user can't go to SuperTokens and revoke their session, isn't the refresh token functionality superfluous?
Also, OAuth is different to session management in that OAuth is for delegation purposes, whilst "a session" can be used to maintain authentication between your own frontend and backend.
In terms of revocation of sessions, our SDK provides functions that can be used to revoke sessions. Soon, we will be making a dashboard that can be used to do the same (and other things)
I'm still a bit confused why you're referencing OAuth here and in the launch announcement while also saying "OAuth is different to session management"
Why have you chosen to use OAuth solutions if you're not solving an OAuth problem? How are you sure it's still the right solution? I see some overlap but it's not obvious to me that OAuth methodologies should be applied here.
Technically, you do not need to exactly follow OAuth methodology for sessions. You are right. However, there is one common problem with sessions and OAuth, which is token theft.
In order to detect token theft, we use the general principle of changing tokens on each use. So theoretically, we can use one random string token, that changes on each use and solve the problem in case of sessions.
In order to make things scalable & have this security benefit, we use two tokens. One that doesn't change, and one that is used rarely, but changes... This starts to look like OAuth now.
Pushing it further, we can name those tokens access and refresh tokens. So while OAuth and sessions are different, we can pick specific concepts from OAuth and apply them to sessions.
I wanted to pile on a little bit here and say this paragraph isn't really comforting to me:
> While unlikely to happen, it is possible for a savvy user to open their browser's developer console, obtain your MagicBell project's API key from your website's source, initialize the widget on their own website with your API key but with a different user's email (if its feasible for them to guess one) and start viewing notifications of that user.
I suspect this was done for developer experience reasons? You seem to know it's not secure to pass in an email directly, especially if anything sensitive is coming across in notifications.
For me at least, allowing the non-HMAC configuration makes me wonder what other security corners have been cut. I'd rather that option didn't exist and the company took a more security-forward stance.