Ory Kratos VS auth0-spa-js

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

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)

auth0-spa-js

Auth0 authentication for Single Page Applications (SPA) with PKCE (by auth0)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
Ory Kratos auth0-spa-js
41 5
10,436 872
5.9% 1.6%
9.6 8.7
6 days ago 6 days ago
Go TypeScript
Apache License 2.0 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.

Ory Kratos

Posts with mentions or reviews of Ory Kratos. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-02-22.

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 Ory Kratos and auth0-spa-js you can also consider the following projects:

Keycloak - Open Source Identity and Access Management For Modern Applications and Services

SuperTokens Community - Open source alternative to Auth0 / Firebase Auth / AWS Cognito

zitadel - ZITADEL - The best of Auth0 and Keycloak combined. Built for the serverless era.

Ory Hydra - OpenID Certified™ OpenID Connect and OAuth Provider written in Go - cloud native, security-first, open source API security for your infrastructure. SDKs for any language. Works with Hardware Security Modules. Compatible with MITREid.

Ory Keto - Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.

OPA (Open Policy Agent) - Open Policy Agent (OPA) is an open source, general-purpose policy engine.

Vault - A tool for secrets management, encryption as a service, and privileged access management

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

authelia - The Single Sign-On Multi-Factor portal for web apps

frank_jwt - JSON Web Token implementation in Rust.

fusionauth-issues - FusionAuth issue submission project

casdoor - An open-source UI-first Identity and Access Management (IAM) / Single-Sign-On (SSO) platform with web UI supporting OAuth 2.0, OIDC, SAML, CAS, LDAP, SCIM, WebAuthn, TOTP, MFA and RADIUS [Moved to: https://github.com/casdoor/casdoor]