Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
Ory Kratos
Next-gen identity server replacing your Auth0, Okta, Firebase with hardened security and PassKeys, SMS, OIDC, Social Sign In, MFA, FIDO, TOTP and OTP, WebAuthn, passwordless and much more. Golang, headless, API-first. Available as a worry-free SaaS with the fairest pricing on the market! (by ory)
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
No problem – I’m happy to engage in good-faith discussions like this one when there are valid nuances to explore.
One callout I’d like to make is that there are two kinds of SDKs. Client-side ones (like Javascript SDKs) and Server-side ones (NodeJS, Go, Python, etc.). The server-side ones are capable of setting HttpOnly cookies, because the server-side ones run on the server and not in a browser context. This is true for both Auth0 and Stytch, and someone using any of the Stytch server-side SDKs will have HttpOnly protection.
Client-side only SDKs are never capable of setting first-party HttpOnly cookies without the aid of a proxy. In fact, there is no truly secure storage mechanism addressable by clientside javascript. All writable storage is accessible to all javascript loaded in the domain - that is to say that if at any point the Auth0 SDK has access to a token, any XSS attack running in the same document will also have access.
Auth0 has numerous clientside SDKs, but we’ll look at their most popular one - @auth0/auth0-spa-js. This SDK stores refresh tokens in a cache [1] in a few ways:
- By default, in memory, which makes exfiltration harder but still very possible via client-side JS. Wrapping a token in a closure doesn’t mean it isn’t addressable - a hacker can monkeypatch and listen to window.fetch for example. This also means that login state is not preserved across tabs or page refreshes, which is quite frankly extremely frustrating to both developers and users
- Auth0 also supports an iframe based flow, which breaks on browsers that use ITP2 such as Safari [2] - so 20% of all users on desktop and 25% of all users on mobile.
- Finally, for customers who do not want the above restrictions, Auth0 allows localstorage [3] to be configured as a cache storage. Local storage is just as open to XSS exfiltration as non-HTTPOnly cookies.
So while yes, Auth0 does not set cookies, their refresh tokens are still accessible client-side in many common deployment scenarios, and are still vulnerable to the same XSS exfiltration vulnerability that HTTPOnly cookies protect against.
Overall, the main reason that Google’s security team, Auth0’s security team, and our security team are comfortable with offering a non-HTTPOnly session management solution in a JS SDK comes down to:
1. HTTPOnly as a security layer can help prevent exfiltration, but if an app already has an XSS vector, it’s already severely compromised, making such a layer moot.
2. As an auth company (whether you’re Stytch vs. Auth0 vs. Google Firebase), you need to make a decision on how much flexibility you want to offer developers. Our stance is that when additional flexibility and an improved developer experience do not create any practical security risk, we should provide that better developer experience to our customers.
[1] https://github.com/auth0/auth0-spa-js/blob/0de9c6bf61d37fc21...
[2] https://community.auth0.com/t/silent-authorization-not-worki...
[3] https://github.com/auth0/auth0-spa-js/blob/0de9c6bf61d37fc21...
One might say you wouldn't be surprised. Security practices at start ups have never been good (no regulation, focus on sales) but to see this lack of security awareness in a company protecting PII is shocking. But what do VCs know ...
As always when something like this happens, here are some good open source alternatives with appropriate security policies and bug bounties in place:
* https://github.com/keycloak/keycloak
* https://github.com/ory/kratos
* https://github.com/GluuFederation (potentially dated for some use cases)
One might say you wouldn't be surprised. Security practices at start ups have never been good (no regulation, focus on sales) but to see this lack of security awareness in a company protecting PII is shocking. But what do VCs know ...
As always when something like this happens, here are some good open source alternatives with appropriate security policies and bug bounties in place:
* https://github.com/keycloak/keycloak
* https://github.com/ory/kratos
* https://github.com/GluuFederation (potentially dated for some use cases)
> just invalidate them after use
I can't speak for Stytch, but I know at $CURJOB, we have run into issues with this where corporate phishing protection software invalidates one time use codes. I believe it does that because it retrieves links in emails before the user clicks on them. This was an issue several of our customers have raised. So it isn't as straightforward as you might think.
There's more details, including the workaround we ended up using, on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/629
PS I agree they should absolutely have guidance around link lifetime as well as safe defaults. Converting the links to one-time use seems like a good start.
Yes, Firebase also stores refresh tokens client-side [1]. The trade-off that both Firebase and Stytch are managing when we follow this pattern is the following:
- You can provide a significantly better developer experience and set-up with this architecture. While there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies by proxying the 3rd party APIs as subdomains, this creates new burdens on the developer for minimal gain considering that a XSS attack vector indicates a severe compromise of the application.
- Today, customers that feel strongly about using HTTPOnly session management will opt for a direct integration with our API using one of our back-end client libraries rather than our JS SDK. While we have interest in providing a HTTPOnly solution in the future to interested customers, we’ve decided the default behavior of the existing SDK is better suited for most developers.
[1] https://github.com/firebase/firebase-js-sdk/blob/0b3ca78eb97...
Related posts
- How to use Lefthooks in your node project?
- Push code with GitHub Actions to Google Cloud’s Artifact Registry
- 6 Tools To Help Keep Your Dependencies And Code More Secure
- 🔒Securing Web: A Deep Dive into Content Security Policy (CSP)
-
firereact VS react-firebase-hooks - a user suggested alternative
2 projects | 5 Feb 2024