Ory Kratos
auth0-spa-js
Our great sponsors
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 |
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
- Show HN: Auth0 OSS alternative Ory Kratos now with passwordless and SMS support
-
Show HN: Obligator – An OpenID Connect server for self-hosters
I was expecting hydra / kratos to show up as an alternative.. but did not see any. Does any have any experience, good or bad about it?
-
Show HN: Blueprint for a distributed multi-region IAM with Go and CockroachDB
I think it would be fair to say that kratos was not the priority in 2022 in terms of code you can see not much was commited (https://github.com/ory/kratos/graphs/code-frequency) so I might have had a bad first impression.
A few issues on kratos that I consider relatively important are still missing / nobody from Ory is giving their input so it's hard to make progress and I would not take my time to contribute if I dont know if the owner are going to merge it.
An example that comes to mind is the OAuth email auto-verification or the search of users that is still super basic (we only recently got the filter of identifiers).
Sorry to hear that this has been your experience! What exactly was the issue for you? It’s true that there are lots of open PRs. We’re a small team and often busy with customer requirements which doesn’t allow us to get a some community PRs over the finishing line.
Sometimes, PRs are also not aligning with an architecture or API concept which is when they often go stale.
Saying that the open source is second class is a false accusation in my view:
- Over 1500 PRs merged in Ory Kratos alone: https://github.com/ory/kratos/pulls
- Show HN: Open-source IAM Ory Kratos v1.0 with Passkeys, MFA and multi-region
-
Show HN: Open-source Auth0 alternative Ory Kratos v0.13 released – nearing v1.0
Check out the milestone on github: https://github.com/ory/kratos/milestone/15
not sure if that is everything.
-
State of OpenID Connect Providers
An open source solution pre-built from professionals like Ory Kratos or Keycloak saves you a lot of time and pain.
-
Tell HN: Stytch Login SaaS Unicorn has common auth vulnerabilities
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)
- Something like Keycloak but in Go?
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.
What are some alternatives?
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]