auth0-angular VS auth0-spa-js

Compare auth0-angular vs auth0-spa-js and see what are their differences.

auth0-angular

Auth0 SDK for Angular Single Page Applications (by auth0)

auth0-spa-js

Auth0 authentication for Single Page Applications (SPA) with PKCE (by auth0)
Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
auth0-angular auth0-spa-js
1 5
168 872
2.4% 1.6%
8.5 8.7
6 days ago 6 days ago
TypeScript TypeScript
MIT License MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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-angular

Posts with mentions or reviews of auth0-angular. We have used some of these posts to build our list of alternatives and similar projects.

We haven't tracked posts mentioning auth0-angular yet.
Tracking mentions began in Dec 2020.

auth0-spa-js

Posts with mentions or reviews of auth0-spa-js. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-10-11.
  • Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities
    6 projects | news.ycombinator.com | 11 Oct 2022
    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...

    6 projects | news.ycombinator.com | 11 Oct 2022
    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
    12 projects | dev.to | 20 Jul 2022
    Auth0 provides the auth0-spa-js package which offers two ways to authenticate users:
  • Persistent login in React using refresh token rotation
    3 projects | dev.to | 17 Sep 2021
    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.

What are some alternatives?

When comparing auth0-angular and auth0-spa-js you can also consider the following projects:

nextjs-auth0 - Next.js SDK for signing in with Auth0

auth0-python - Auth0 SDK for Python

AppAuth-JS - JavaScript client SDK for communicating with OAuth 2.0 and OpenID Connect providers.

auth0-react - Auth0 SDK for React Single Page Applications (SPA)

feedback - Feedback, Ideas and Suggestions for our articles

auth0-javascript-samples - Auth0 Integration Samples for Vanilla JavaScript Applications

fastify-vite - Fastify plugin for Vite integration.

fastify-dx-solidjs-example - Real world app using Fastify-DX, Solid.js, Auth0 and GraphQL

auth0-java - Java client library for the Auth0 platform

universal-router - A simple middleware-style router for isomorphic JavaScript web apps

fastify-dx - Archived

solid-devtools - Library of developer tools, reactivity debugger & Devtools Chrome extension for visualizing SolidJS reactivity graph