auth0-spa-js
auth0-java
Our great sponsors
auth0-spa-js | auth0-java | |
---|---|---|
5 | 129 | |
872 | 278 | |
1.6% | 2.2% | |
8.7 | 8.2 | |
6 days ago | 2 days ago | |
TypeScript | Java | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
auth0-spa-js
-
Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities
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...
Your message feels disingenuous and not in good-faith.
Auth0 clearly advises against the localStorage option which is most similar to Stytch's:
> _Important:_ This feature will allow the caching of data _such as ID and access tokens_ to be stored in local storage. Exercising this option changes the security characteristics of your application and _should not be used lightly._ Extra care should be taken to mitigate against XSS attacks and minimize the risk of tokens being stolen from local storage.
This is from the readme of the github you linked:
https://github.com/auth0/auth0-spa-js/tree/0de9c6bf61d37fc21...
And since their other client-only solutions have major UX challenges (as you highlight), I expect most Auth0 users have landed on the secure option.
This is very different from Stytch - which as far as I can tell - doesn't disclose or acknowledge the risk, and instead willingly puts developers at increased risk. Throughout this thread, you've been dismissive of the risk despite security organizations clearly indicating that HttpOnly is best-practice.
You've found a legitimate comparison in Firebase, but for me, you've taken several steps too far trying to compare to Auth0.
-
Fastify DX and SolidJS in the Real World
Auth0 provides the auth0-spa-js package which offers two ways to authenticate users:
-
Persistent login in React using refresh token rotation
Therefore, I have transformed the library [@auth0/auth0-spa-js](https://github.com/auth0/auth0-spa-js), which is another official Auth0 client library, to have an authentication hook and methods that can be accessible outside the components.
auth0-java
- What features would you consider missing/nice to haves for backend web development in Rust?
-
Does anyone know how to make an animation like on Auth0 website?
The animation I'm referring to is the sliding up text in the hero section
-
Quickly Build Secure Microservices in Python
Protect endpoints using JWT security with a OpenID Connect IAM like Auth0 or Keycloak Optionally control access to endpoints using RBAC
-
Auth0 Provider and Strapi Tutorial
Auth0 is an adaptable authentication and authorization platform. Auth0 takes out the pain of developing a full authentication system from scratch for your application and managing user credentials by yourself.
-
How to implement a basic CRUD in Golang protected by Auth0
First things first, you need an account on the Auth0 platform, so head to their page and create one.
-
The problem(s) with Azure Functions
Functions can be triggered in multiple ways: HTTP, Queue, Db, Blob Storage Change and many more. More on this can be found here. This was one of the major reasons why I thought Azure Functions are great. I mostly needed the HTTP and Queue trigger. With HTTP functions comes also the requirement for Authentication and Authorization. I'm using Auth0 as an authentication provider. The implementation is usually straightforward. The frontend obtains an access token and the API validates the token and authenticates the request. OpenID connect is well documented and somewhat easy to use in asp.net core for example. Not with Azure Functions I googled for days, opened an issue and tried everything I could think of and came to the conclusion: Microsoft doesn’t provide you with proper SDKs to handle authentication adequately.
-
System Design: The complete course
Auth0
-
How to get funds for an open-source company 💵
There are more and more products getting into the market every day that need to deliver a lot of features. Sometimes those things become super complex, and the main thing they usually don’t have is time. A lot of those parts are engineers issues that can be democratized by open-source solutions. You can use Okta for the identity solution, Add Auth0 for authentication, and then use Permit for authorization and you have easily saved thousands of development hours.
- Conditionally rendering
-
Using AWS JWT authorizers with Auth0
Say that we have decided to use Auth0 for authorization in our architecture. We want to give users with different sets of permissions access to different levels based on their permissions.
What are some alternatives?
nextjs-auth0 - Next.js SDK for signing in with Auth0
metamask-extension - :globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
next-auth - Authentication for the Web.
testcontainers-spring-boot - Container auto-configurations for Spring Boot based integration tests
auth0-angular - Auth0 SDK for Angular Single Page Applications
supabase - The open source Firebase alternative.
auth0-python - Auth0 SDK for Python
AppAuth-JS - JavaScript client SDK for communicating with OAuth 2.0 and OpenID Connect providers.
akka-http-pac4j
microsoft-authentication-library-for-js - Microsoft Authentication Library (MSAL) for JS
frank_jwt - JSON Web Token implementation in Rust.
netlify-identity-widget - A zero config, framework free Netlify Identity widget