Sick of spending time on Auth, we built an open source 'Stripe for Auth'
347 comments
For my little web app I just went with passwordless logins and did the "magic token sent to the inbox" thing. I no longer have to deal with passwords at all; a security breach is (mostly) useless in terms of mining creds; and all of the password handling workflows are now the email provider's problem.
If someone loses access to an email account then I can use manual processes to verify the person and change the email address in the database. This has never happened.
EDIT: "fault" => "problem"
If someone loses access to an email account then I can use manual processes to verify the person and change the email address in the database. This has never happened.
EDIT: "fault" => "problem"
I had to do this on a recent project because Corporate IT departments sometimes flag anything that has a create account / login prompt with a password field. Once you get on their shitlist it can take months of fighting the red tape machine to get off of it again. So we bypassed that with passwordless login using email.
Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.
Unrelated, but we also discovered that one corporate had some kind of batshit crazy network where requests would be routed through different exit IP addresses in different regions for the same user. On top of that, 5 seconds later it would repeat a request. Not just GET requests either, but also POST requests. How they get by without horrible things happening is beyond me. This completely broke user sessions since any login attempt would be followed by a second login for the same user which invalidated the session token. Imagine trying to use your online bank with that network. If anyone has seen anything similar in the wild, I'd love to hear from you. We never figured out what software they have that does that. We changed how our sessions work to get around it, but it probably ranks as the most bizarre issue I've encountered in my 20 year career.
Not that uncommon for large companies to bring their IP space in house to multihome and load-balance traffic across multiple providers. If they are routing traffic back to random data centers for centralized filtering, it makes sense how it could be coming from different regions. I'm more interested in what made your application sensitive to this. The duplicate packets does sound bizarre. Maybe a mirroring issue or firmware issue.
The changing ips were ok, it just made diagnosing the issue difficult in the logs. The duplicate requests (not at the packet level as TCP ignores duplicate packets) were the root cause of the issue.
Reminds me of the "fun" of dealing with a RADIUS system that would, about 20% of the time, send me two START packets for the same session ... with different sequence numbers.
This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)
This made successfully managing dynamic IP pool allocation on my end an ... interesting ... experience ;)
> We changed how our sessions work to get around it
In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with.
The only real quibble here might be that duplicate requests cost you unnecessary transit.
In other words, you fixed the bugs in how your original implementation relied on bad assumptions that it shouldn't have tried to rely on to begin with.
The only real quibble here might be that duplicate requests cost you unnecessary transit.
Duplicate POST requests are a violation of the HTTP standard because they are not assumed to be idempotent. I hope you're just misunderstanding the problem.
[deleted]
I have tried something similar, although I am encountering issues with people having to wait 10+ minutes for their codes at times, yet sometimes it arrives immediately, which is frustrating when it comes to login.
I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!
I haven't spent any time debugging in depth yet, apart from looking at the email headers and seeing that it takes over 5 mins for the email to get from SES to Gmail. Not sure why!
MXroute has a blogpost where he digs into this a bit. IIRC it actually gets accepted by Google immediately - but then spends 5mins in the ether inside Google before it hits a Gmail inbox. No way to tell what the delay is coming from, other than it appears to be out of our hands.
Edit: https://mxroute.com/delayed-delivery-to-gmail/
Edit: https://mxroute.com/delayed-delivery-to-gmail/
There's a great project called Portier [0], which does this quite nicely. I highly recommend it.
It's a successor of sorts to the ill-fated Mozilla Persona project [1].
> Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.
[0]: https://portier.github.io/
[1]: https://en.wikipedia.org/wiki/Mozilla_Persona
It's a successor of sorts to the ill-fated Mozilla Persona project [1].
> Portier (pronounced "Por-tee-ay") is a self-hostable login service that you can use instead of passwords. Portier sits between your website and third-party services like Google Sign-In to provide your users the fastest and easiest login experience, without ever needing a new password.
[0]: https://portier.github.io/
[1]: https://en.wikipedia.org/wiki/Mozilla_Persona
This is a really cool idea.
So they basically go to their email and verify and it stores a token in their cookies?
So they basically go to their email and verify and it stores a token in their cookies?
Exactly.
They login by just providing their email. It sens a link with a unique code in it. This code is checked against the DB and if it's correct, they get a cookie (the digital kind ;])
They login by just providing their email. It sens a link with a unique code in it. This code is checked against the DB and if it's correct, they get a cookie (the digital kind ;])
Beware of setups that verify (i.e. visit) all links in an email upon receiving one. This completely breaks one-time use login links.
I know I'm the exception but as a privacy oriented user I hate this. There are services that try to track me across the net when I'm logged in so I never log into them except in a private window. This works great when my browser has the name/password saved because I go to the site and its one click to login. It sucks though when it's email login. I now have to click "login", wait 10 second to 3 minutes for the email to arrive. Copy the link from the email to the private window. It basically means I avoid using that site most of the time. (Medium)
You're not my target audience and you have an esoteric approach to privacy.
Most of my friends/family who use work laptops/computer do the same thing - they log in via a private browser so they don't get work credentials mixed with personal credentials.
I think firefox containers are a great way to handle this, and a lot of folks don't know how to use chrome or other browsers with multiple identities.
Maybe look past that this user is doing it for privacy.
I think firefox containers are a great way to handle this, and a lot of folks don't know how to use chrome or other browsers with multiple identities.
Maybe look past that this user is doing it for privacy.
I believe the inconveniences are worth it when your users aren't power users or even that proficient with a computer; and your users select passwords like "snoopy55" or "ilovejesus".
If the aim of the game is to produce a non-critical system that's accessed rarely, and your users need protecting against themselves, then this "magic token" approach works fine.
I can't please everyone, and those who I can't please I'm happy to lose as (paying) users/customers.
If the aim of the game is to produce a non-critical system that's accessed rarely, and your users need protecting against themselves, then this "magic token" approach works fine.
I can't please everyone, and those who I can't please I'm happy to lose as (paying) users/customers.
Those people are also far more likely to have their email breached, along with the logins you provided on a silver platter. Also they can't log in to your site when the third party email provider goes down. I understand why you prefer this approach for your site, but can not recommend having such strong third party dependencies.
Also, personally, not a fan of losing access because e.g: Google disabled my account. I avoid google and fb login like the plague. (I am slowly looking to migrate off/away)
Also, personally, not a fan of losing access because e.g: Google disabled my account. I avoid google and fb login like the plague. (I am slowly looking to migrate off/away)
Using private browsing to minimise tracking is absolutely not esoteric.
Would something like Firefox's containers(?) help you for these sites? There's a way to leave a single tab signed in without having it leak the fact that you're logged in to your other browser tabs, rather than logging in each time you use the site in a new private session. It's even possible to log in to the same site on multiple accounts with this feature.
> There are services that try to track me across the net when I'm logged in so I never log into them except in a private window.
I'm sure you can have a browser extension to block cookies and other tracking information on these sites.
I use Brave with maximum security and privacy settings with a VPN in addition to using Tor and haven't had any issues.
I'm sure you can have a browser extension to block cookies and other tracking information on these sites.
I use Brave with maximum security and privacy settings with a VPN in addition to using Tor and haven't had any issues.
FWIW, I hate this about the couple of apps I use that do this (with no other option, e.g. Notion added a password option).
And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect.
It's especially annoying when setting up a new device - oh right yes, obviously I need to set up my email app before this one...
And what if I don't have or want or can't currently for whatever reason receive email on that device? Now I'm trying to get it there by some other means, only to find it times out in the process.
(This is all happened to me, and enough that I'm ranting about it...)
And not for privacy concerns, as a sibling thread is discussing, but simply because I find it considerably less convenient than a password, as most things use, and as I'm set up to conveniently use and expect.
It's especially annoying when setting up a new device - oh right yes, obviously I need to set up my email app before this one...
And what if I don't have or want or can't currently for whatever reason receive email on that device? Now I'm trying to get it there by some other means, only to find it times out in the process.
(This is all happened to me, and enough that I'm ranting about it...)
For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse.
But for certain things that I need to do say once a year (let’s say renew some kind of registration or insurance) I wouldn’t mind it. Because chances are I already do this because I forgot to save the password in my password manager last time and now I need to do a reset password flow anyway.
But for certain things that I need to do say once a year (let’s say renew some kind of registration or insurance) I wouldn’t mind it. Because chances are I already do this because I forgot to save the password in my password manager last time and now I need to do a reset password flow anyway.
> For anything I use with any kind of regularity I’d hate it. I already have this problem with services that decide they really need to send me some code by email because they don’t recognize my device (because it’s been more than 30 days and Safari killed their cookies). And then every once in a while the email doesn’t show up for 45 minutes for some reason, leaving me with no recourse.
It's incredible to me how impatient we've become as a society.
As everything is given to us faster and faster, with less and less financial cost, the more we demand this of everything going forward. Anything that comes shy of this demand by mere minutes is shunned as unacceptable.
It's incredible to me how impatient we've become as a society.
As everything is given to us faster and faster, with less and less financial cost, the more we demand this of everything going forward. Anything that comes shy of this demand by mere minutes is shunned as unacceptable.
I don't get this comment. I've been in plenty of situations where I need something now. Doctors office, DMV, tax office, etc...
It's not about being impatient. It's about knowing that it should be instant and it not being instant. If you turned on your water faucet, shower, or flushed your toilet and water didn't run for 45 minutes most people would be shocked.
It's not about being impatient. It's about knowing that it should be instant and it not being instant. If you turned on your water faucet, shower, or flushed your toilet and water didn't run for 45 minutes most people would be shocked.
> Flush Button Push Detected
> Contacting Toilet Cloud Server...
> 503 Service Unavailable
> Alert User: "Water Unavailable, Please try Later."
> Contacting Toilet Cloud Server...
> 503 Service Unavailable
> Alert User: "Water Unavailable, Please try Later."
In a strange sense, I feel this joke is not too far from reality.
> I'm really glad I decided to meditate and learn to be a more patient person.
A friendly nudge: google 'spiritual ego trap' and then read this comment again.
A friendly nudge: google 'spiritual ego trap' and then read this comment again.
I don't believe that's required.
I'm not saying I'm better than anyone else, I'm simply pointing out that having now slowed down and become more patient, I don't complain when accessing information from the other side of the planet takes 3 minutes instead of 3 seconds.
That is what this essentially boils down to: convenience and patience. We're losing the latter because of the former.
I'm not saying I'm better than anyone else, I'm simply pointing out that having now slowed down and become more patient, I don't complain when accessing information from the other side of the planet takes 3 minutes instead of 3 seconds.
That is what this essentially boils down to: convenience and patience. We're losing the latter because of the former.
You may want to work on your phrasing then, because that was sure the way it came off. You say that culturally we’re a certain way and then that you feel that you’re a better person for being different.
I'll take onboard for next time. Appreciate it.
I access almost all services in private tabs, i.e. cookies are not persisted, and let my password manager do the login.
I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on.
There's something very appealing about not having a password that I need to store anywhere for that service too.
There's something very appealing about not having a password that I need to store anywhere for that service too.
> I don't love this either, but it's basically the same inconvenience as having multi factor authentication turned on.
MFA usually uses channels that are intended to be relative low latency (or that don't require realtime out-of-band transmission, like TOTP).
Email, OTOH, isn't generally reliably low-latency
MFA usually uses channels that are intended to be relative low latency (or that don't require realtime out-of-band transmission, like TOTP).
Email, OTOH, isn't generally reliably low-latency
Is there a technical detail of email that I don't know about that makes it less low-latency than a text message?
Email or text would work the same for this auth scheme anyway.
Email or text would work the same for this auth scheme anyway.
tangent: SMS doesn't have the security needed for most things. We can let it be a part of auth when combined with another factor, albeit begrudgingly.
SMS can be delivered days late. It isn't any better than email.
And as I discovered in my own service: If the SMS aren't being sent - or the clients aren't getting them - there are so many parts involved that's really hard to pinpoint the problem and get an ETA for the solution..
E-mail, especially when the MTA and MUA is connected to different environments, which requires relaying, could be particular slow (minutes, hours) if the e-mail hops on busy services.
Yeah, I am not a fan of magic tokens / login by email address either. It's a pain to need to message yourself with a token url and then the messenger app does previews which renders the token invalid and then you need to save a text file with the url in it, send it open it, copy paste the url into the browser. Just to login.
Sure, you could say, why don't setup your email on your devices but I shouldn't need to do that. Just to use your website. These magic links are just not user friendly
Sure, you could say, why don't setup your email on your devices but I shouldn't need to do that. Just to use your website. These magic links are just not user friendly
I am not too privacy oriented like another post. I just don’t like having to go to my email to log in. It’s a hassle vs my saved password being auto filled or using an Oauth login. But Most other people seem to shrug it off and do it. So seems like it’ll keep becoming more common.
This is just being lazy over customer experience.
I don't like having have to click the link, trash the email and close the previous login tab.
> I can use manual processes to verify the person
What does this mean?
I don't like having have to click the link, trash the email and close the previous login tab.
> I can use manual processes to verify the person
What does this mean?
I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API.
[0]: https://magiclogin.net
[0]: https://magiclogin.net
isn't that the same as https://magic.link?
The base idea is the same yes, but the pricing and featureset are different.
Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing).
tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.
Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing).
tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.
What would your pricing be? Starter pack at $35/month for 500 users sounds like $35/month and I outsource auth to a company that is also on the hook for “enterprise” security :)
I think it’s awesome you’re building an alternative with a different feature set, I’m really curious to hear your take on pricing.
I think it’s awesome you’re building an alternative with a different feature set, I’m really curious to hear your take on pricing.
The pricing is listed on the website, but it's about 10-20% of that. You would pay around 0.50 per 1000 emails. Depending on how often your users sign in and how long you keep them logged in for the the percentage may be lower or higher.
Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.
Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.
I’m not very vested in a solution at the moment, but if I had a set of users < 500, the flat pricing of Magic Link kind of makes more sense to me, I don’t want to be worrying about how many times they sign in.
That being said, I can imagine there are people who would prefer a per sign in model, it’s just a level of granularity I don’t care for.
Good luck!
That being said, I can imagine there are people who would prefer a per sign in model, it’s just a level of granularity I don’t care for.
Good luck!
This my friend is utterly brilliant!
Username + password is nice when you have a password manager that auto-inserts the credentials for you into the form. The 1Password extension and browsers with builtin password managers do this. All I have to do is click login and I’m in. The magic link flow is more of an inconvenience in this regard because it involves jumping around apps.
As an alternative...I wonder if there could be a auth process where the user creates a writeable 'space' for a site/app with a one time key in their password manager, gives the site/app the key, then the site uploads new login credentials directly into the password manager.
So there is no way to login on any device that isn’t your own?
You can login to any device on which you can login to your email. Most people can login to their from anywhere, on any device, via a browser.
I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.
I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important.
> I'm not really targeting people who will want to work from multiple devices and the app its self isn't really that important
So basically this is not a solution for 99% of all services. Thanks for clarifying
So basically this is not a solution for 99% of all services. Thanks for clarifying
You're right, Slack isn't really that popular and totally doesn't use magic tokens /s
You can extend this idea to include a one time code in the email that can be manually typed on another device.
Including a QR code of the link also helps.
Including a QR code of the link also helps.
Another bonus with magic links. In my experience people pay waaaay more attention to their email accounts than they do to almost any other authentication system they interact with. So chances are higher that they'll have a secure password, rotate their password, maybe even have MFA. (I said higher, but I didn't say likely ;) .)
Anyway, I think for certain kinds of applications this is a fantastic auth solution.
The only possible downside is that you've introduced a dependency on mail deliverability into a core piece of your application. But email deliverability may be a big enough issue that you want it solved anyway.
Anyway, I think for certain kinds of applications this is a fantastic auth solution.
The only possible downside is that you've introduced a dependency on mail deliverability into a core piece of your application. But email deliverability may be a big enough issue that you want it solved anyway.
I did the exact same for a recent project, a small internal tool for geo data collection in cities. It comes with tradeoffs as others have mentioned but it’s pretty great for getting something going quickly with a small number of users. All you need is mailgun or similar key and you’re off.
I don't mind this. 7/10 times I'm doing the password reset thing already when I visit a site I don't use much but know I have an account with, so this just cuts to the chase
I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link
I'm already logged into Chrome browser, thus gmail, so it would be great if I didn't have to manually go over to gmail and click your link
Implemented this recently in my SaaS app, replacing passwords with magic links and it was a mistake. Sure, it has some obvious benefits: it forces users to always provide a valid email and logging in confirms that the email address is valid, without any additional logic.
But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth.
Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal.
Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.
But moving auth logic to email links has increased my customer support work significantly: "I can't log in", "I didn't get the link" complaints are quite common now. People use email they didn't sign up with, messages go to spam, arrive with a delay - or recently, gmail outage caused messages to hard-bounce. These are only some of the issues I've had to deal with in the last few weeks, that never came up when I had password auth.
Also, I've found that some email clients automatically follow links included in the message and that meant login link was invalidated before user got a chance to click it. I've solved it by adding a button on the page, but it's not ideal.
Magic links were supposed to be convenient, but they cause a lot of frustrations for some users. Keep that in mind.
I was bitten by this issue already two times. First time wth magic links via email. Suddenly your application depends on the mail infrastructure that sometimes is hard to "scale on demand" or even isn't under your control. Second time with OTP via SMS. Both incidents led us to be unreachable for long periods of time, and the SLA provided by our mail provider and telecom weren't really known until the incident. We assumed that everything would just work under high load.
Quality insight from someone who has actually gone through this. Thank you!
If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved?
Also, do you still continue that (Email login / OTP login) OR is it moved something else?
If you could share, can you share what exactly led to the discovery that things are unreachable. Were there any status check mechanisms you were able to put in place to check that incident was raised and / or solved?
Also, do you still continue that (Email login / OTP login) OR is it moved something else?
> If you could share, can you share what exactly led to the discovery that things are unreachable.
We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers.
After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc.
> Also, do you still continue that (Email login / OTP login) OR is it moved something else?
The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it.
The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.
We have some heavy monitoring with InfluxDB and Grafana built in our application and one of the alerts is if the number of logins/minute drop under a threshold. That's how we noticed it first time. The main reason was some network issues affecting our mail server provider. We were holding on a support ticket with our provider while trying to find a solution to our customers.
After that we added as well we extended this monitoring to the mail queue. To be fair we used to monitor it before, but with the infra team, now we have it in our SRE dashboard, with Slack notifications and etc.
> Also, do you still continue that (Email login / OTP login) OR is it moved something else?
The OTP as second factor of authentication is something that we couldn't disable, but it's a requirement for one very specific application. We just looked for different partners with better SLA and built some monitoring around it.
The Email login is still there, but we didn't roll-out it to all our applications as we initially intended to. We are still studying what would be the best solution here. The company is heavy user of microsoft's 365 mail service, and although the overall experience is pretty good, we have 0 influence in their SLA if we get impacted by any issue on their side. I don't think that the solution is bad per-se, just you have to plan mail infrastructure as core part of your application.
especially on corporate vpn
This is so annoying as a user! It’s like you’re making me do a password reset every time I want to log in, and I have to sit there and wait until the email arrives.
> password handling workflows are now the email provider's problem.
if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)
if the web app isn't critical, I think that's a great solution. If the application is critical, then you have to pull in the e-mail system as critical component from your application (as critical as the database, application server and etc)
I know most people are not like this, but I don’t mind setting up auth “over and over”
It’s always a chance to read about what’s changed in the technologies/ideas you usually lean on for it. Apply that simplification that you wish you could have for your already launched application. Maybe you have a need to make your auth slightly more proprietary. If you churn out applications all the time yeah I get why this could all be seen as a waste of time.
I don’t say this to belittle your service at all, looks neat! Just throwing out an alternative viewpoint for the sake of it :)
It’s always a chance to read about what’s changed in the technologies/ideas you usually lean on for it. Apply that simplification that you wish you could have for your already launched application. Maybe you have a need to make your auth slightly more proprietary. If you churn out applications all the time yeah I get why this could all be seen as a waste of time.
I don’t say this to belittle your service at all, looks neat! Just throwing out an alternative viewpoint for the sake of it :)
I never did it, what is a good guide to start? Thanks!
OWASP is a good resource for web security related topics. i.e. https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...
Hey! I don’t have a guide on hand, maybe another commenter will see this and have some resources :) Honestly my experience is just collected from 10 years working with and around other web applications, and as such is a bit ephemeral. I’d say any guides out there on the topic will arm with you enough knowledge to get started, or even working with services like the subject of this post. You’ll see the pieces at play in action, and can learn from them.
I hate doing auth and commodity features like user admin along with SSO integration, and hooking it all up to both the front and back end. I'd rather be busy doing business related features.
Nothing wrong with that, that’s the right mindset for getting things done
Ofcourse, everyone has their own preference. Thats an interesting perspective as well. My only counter to that would be that its time consuming to roll your own auth for a complex or large scale app. It starts off easy but soon you have to make significant investments in various aspects of auth. That isnt true for all apps ofcourse. Definitely good to keep learning though!
Part of it too is that I tend to work on smaller projects that don’t grow and change indefinitely like startup saas does. If you’re getting something up quickly where the requirements will change all the time, a service like this starts to make way more sense :)
Yes, thats exactly it - from our experience with talking to devs and startups. Once the project starts scaling, things change
Yeah I don't mind setting up auth. It takes like a week at most for your MVP.
Depends what you mean with "setting up auth". Once you get into enterprise scenarios, where you need SSO for SSH, Git, your public website, internal tools, ability to revoke accesses, handle trusted mobile devices (ie generating QR codes for VPN/Wireguard access), handling 2FA, etc, etc, it takes more than a week. For such scenarios, doing it yourself and doing it correctly becomes immensely difficult.
Agreed. Done right it's a huge time suck.
I’m building a MVP to show off and validate some ideas. I’m using Firebase and set up auth with my react app in about 10 minutes. I’d never spend a week on auth for a MVP.
I was talking about rolling you own email/password auth from scratch. I keep hearing about Firebase and how easy it is. Is that like AWS Cognito? Does it have custom branding or is it a drop-in form? Can it be hooked to your own SQL database?
It's far easier than AWS Cognito. Yes, I've used both.
Firebase auth is as easy as it gets for auth. Want Username/Pass? Just enable it. Want Google, Twitter, Firebase, Apple, Github, etc.? Just enable it, and write the handlers.
Want to hook into your own SQL database? Easy. Set up a firebase listener, that handles the auth event, and write whatever you want (username, auth details) to SQL.
This is a 100% solved problem and Firebase does a superb job it it.
Firebase auth is as easy as it gets for auth. Want Username/Pass? Just enable it. Want Google, Twitter, Firebase, Apple, Github, etc.? Just enable it, and write the handlers.
Want to hook into your own SQL database? Easy. Set up a firebase listener, that handles the auth event, and write whatever you want (username, auth details) to SQL.
This is a 100% solved problem and Firebase does a superb job it it.
Awesome, this is great to know. I'll have to consider it for my next side project. Unfortunately I just finished rolling my own, so... :)
I am annoyed at doing auth over and over, when it's other people's software. The promise of the container revolution was that cross-cutting concerns would be handled by the infrastructure / orchestrator, and applications wouldn't have to care about details like authentication, monitoring, logging, etc. None of that really materialized, though. The actual running/scheduling of workloads is currently in a great state, but the cross-cutting concerns are pretty awful. Or actually, they're good, but very much "bring your own". I use managed Kubernetes, but it doesn't give me managed monitoring, managed logging, managed authentication, etc. (Cloud providers sell that, but you have to do all the integration work. Some random Go binary you download won't accept Identity Aware Proxy JWTs and send your metrics to Stackdriver. You have to make that all work yourself.)
I've run into the situation at least twice where some app has bought into that mindset and made auth an external factor (don't send HTTP requests unless the user is authorized), and found that there was pretty much nothing good to provide that feature. So... I wrote my own thing both times, and am loving it. (You could use it too! But I wouldn't necessarily recommend it: https://github.com/jrockway/jsso2) I never have to think about auth again.
Having also done the infrastructure and library work to get Prometheus/Grafana/Jaeger/Loki doing what I want (https://github.com/jrockway/opinionated-server), I am almost happy with the remaining cross-cutting concerns. I am ever closer to my "1 hour app", where I can just type in some code and have a fully-working production-quality app available to users. I'm not there, but I'm getting closer by the year.
(Sometimes I wonder if we were wrong to totally get rid of the "just rsync some PHP files to a server" model. There were good things and bad things going on there; we should bring the good things back.)
I've run into the situation at least twice where some app has bought into that mindset and made auth an external factor (don't send HTTP requests unless the user is authorized), and found that there was pretty much nothing good to provide that feature. So... I wrote my own thing both times, and am loving it. (You could use it too! But I wouldn't necessarily recommend it: https://github.com/jrockway/jsso2) I never have to think about auth again.
Having also done the infrastructure and library work to get Prometheus/Grafana/Jaeger/Loki doing what I want (https://github.com/jrockway/opinionated-server), I am almost happy with the remaining cross-cutting concerns. I am ever closer to my "1 hour app", where I can just type in some code and have a fully-working production-quality app available to users. I'm not there, but I'm getting closer by the year.
(Sometimes I wonder if we were wrong to totally get rid of the "just rsync some PHP files to a server" model. There were good things and bad things going on there; we should bring the good things back.)
Thank you for open sourcing these libraries. Your mindset of an app in an hours really strikes me as ple
asant. I’ve used PHP Yii framework and everything used to work that way. From layout till auth till database modelling and generating everything based on that. Loved it! I spent most of my time working in MySQLWorkbench perfecting the database model and the rest was more or less generated.
Anyway, I’ll definitely look into your libs!
Anyway, I’ll definitely look into your libs!
Something else to consider for Auth is Dex: https://dexidp.io/
That is useful for the case where the application you want to run supports OAuth (OIDC actually), and you want to be your own identity provider. The app has to go out of its way to support OIDC, but it's so common that it might be good enough for normal people. And you can turn Dex or another OIDC provider into an authenticating reverse proxy with: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extension...
(I started writing jsso2 before this existed, and didn't want to tie myself to Envoy necessarily... but if I were starting from 0 today, I'd probably just use Dex and that Envoy extension. Seems simple, and has a lot of corporate support behind it for maintenance / security.)
That is useful for the case where the application you want to run supports OAuth (OIDC actually), and you want to be your own identity provider. The app has to go out of its way to support OIDC, but it's so common that it might be good enough for normal people. And you can turn Dex or another OIDC provider into an authenticating reverse proxy with: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extension...
(I started writing jsso2 before this existed, and didn't want to tie myself to Envoy necessarily... but if I were starting from 0 today, I'd probably just use Dex and that Envoy extension. Seems simple, and has a lot of corporate support behind it for maintenance / security.)
It's fine if you have the sponsor to pay for your time to deeply understand all the security protocols required and to keep up-to-date with those as well as their different implementations.
But complexity is the worst enemy of security because it easily creates loopholes in security. I think anything that can be done to simplify security will exponentially improve security.
But complexity is the worst enemy of security because it easily creates loopholes in security. I think anything that can be done to simplify security will exponentially improve security.
I have my own auth solution that I carry with me. If my employer or client has a better auth solution, great I use their's, else I'll give them mine. Which is basically a working implementation of Spring OAuth. And I keep it updated as Spring updates it. I feel that knowing one solution well enough that you can implement any reasonable use case is better than constantly learning and dealing with the shortcomings of other solutions.
When you learn Spring OAuth well enough you can basically bend it to your will. It provides enough hooks and interceptors to do whatever you want. But it has a steep learning curve.
When you learn Spring OAuth well enough you can basically bend it to your will. It provides enough hooks and interceptors to do whatever you want. But it has a steep learning curve.
Usually what happens to me on side stuff, is I spend so much time on the basic setting up auth and other things that are done over and over.......I burn out and never actually make the business logic of the app lol.
SuperTokens looks really cool and I'm glad it's open source, however, I think the big "blue ocean" here for self-hosted auth systems vs. AWS Cognito and Auth0 are security compliance.
Many large orgs with data requirements need things like ISO 27001, FedRAMP, etc. If you build with a product like SuperTokens and then need to meet these requirements later in your development lifecycle, you'll have to:
a. switch to Cognito/Auth0 for ISO, and for FedRAMP you can only use Cognito.
b. modify SuperTokens by learning NIST requirements (costs engineer time, developers might not know Java)
c. you can make your own, but that defeats the purpose for these systems (costs more time than b)
I feel an "Enterprise" (paid) option by SuperTokens where security compliance is handled, with still the option for self-hosting, would be a massive win.
Many large orgs with data requirements need things like ISO 27001, FedRAMP, etc. If you build with a product like SuperTokens and then need to meet these requirements later in your development lifecycle, you'll have to:
a. switch to Cognito/Auth0 for ISO, and for FedRAMP you can only use Cognito.
b. modify SuperTokens by learning NIST requirements (costs engineer time, developers might not know Java)
c. you can make your own, but that defeats the purpose for these systems (costs more time than b)
I feel an "Enterprise" (paid) option by SuperTokens where security compliance is handled, with still the option for self-hosting, would be a massive win.
Thats incredibly insightful because that is exactly our plan :)
We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail
We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail
> We will follow the Buyer based model where features for developers / startups are free and those required by enterprises are paid. We have a section on pricing philosophy on our pricing page that explains this in a little more detail.
Just curious about this model, but if you keep only the essential features on the developer plan (good for startups but not much above that), while the enterprise plan requires more complicated features and SDKs that you may not be able to provide just yet because it would be expensive at this stage, wouldn't it be a catch-22 situation of sorts?
Just curious about this model, but if you keep only the essential features on the developer plan (good for startups but not much above that), while the enterprise plan requires more complicated features and SDKs that you may not be able to provide just yet because it would be expensive at this stage, wouldn't it be a catch-22 situation of sorts?
Sorry, I am not sure I completely understand. When you say that we may not be able to provide because it would be expensive - do you mean it would be expensive for us to build or for startups to buy? What exactly would the catch 22 situation be?
What Aeolun said. Basically if you don't provide those features that enterprise wants from the get-go, and count on the enterprise plan to fund the development of those features, doesn't that land you in a catch 22?
Not that I'm criticizing your model, but I'm just genuinely curious. I would switch to using this in a heartbeat if it doesn't end up too complicated. And lots of thanks to other HNers for downvoting me when I asked an honest question on SaaS pricing.
Not that I'm criticizing your model, but I'm just genuinely curious. I would switch to using this in a heartbeat if it doesn't end up too complicated. And lots of thanks to other HNers for downvoting me when I asked an honest question on SaaS pricing.
FusionAuth (the company for which I work) have a similar model with a free (though, in our case, not open source) community edition for developer reach and to lower the barrier to entry.
Then support and enterprise features are paid for by the enterprise. If you can find the right levers, it works.
This has been a common business model. Redhat did it, Hashicorp does it, Rancher I believe as well. The entire SSO Tax group of companies ( https://sso.tax/ ) have variable pricing because companies will pay for features like SSO that devs won't.
The question, especially with an open core model, is what happens if the cloud providers do to you what they did to mongo or elastic. I found this article interesting: https://joemorrison.medium.com/death-of-an-open-source-busin...
I think the jury isn't out on opencore as a business model and auth is certainly the right kind of horizontal platform play. And there's certainly room for all kinds of business models in auth, as it's a gigantic market.
Disclosure: I work for FusionAuth.
Then support and enterprise features are paid for by the enterprise. If you can find the right levers, it works.
This has been a common business model. Redhat did it, Hashicorp does it, Rancher I believe as well. The entire SSO Tax group of companies ( https://sso.tax/ ) have variable pricing because companies will pay for features like SSO that devs won't.
The question, especially with an open core model, is what happens if the cloud providers do to you what they did to mongo or elastic. I found this article interesting: https://joemorrison.medium.com/death-of-an-open-source-busin...
I think the jury isn't out on opencore as a business model and auth is certainly the right kind of horizontal platform play. And there's certainly room for all kinds of business models in auth, as it's a gigantic market.
Disclosure: I work for FusionAuth.
As a (potential) consumer of this type of service I can attest that this is fine with me.
I had a SAAS for a while where <large enterprise customer> insisted on SAML-based authentication for a full roll out. However, they were happy to do a (cheaper) paid trial without it.
A service like SuperTokens works well here because its costs and complexity scale with my requirements. Unlike Congnito it is literally free and completely under my control at the start, but there is a reasonable forward migration path that doesn't involve a complete auth rewrite going forward.
I had a SAAS for a while where <large enterprise customer> insisted on SAML-based authentication for a full roll out. However, they were happy to do a (cheaper) paid trial without it.
A service like SuperTokens works well here because its costs and complexity scale with my requirements. Unlike Congnito it is literally free and completely under my control at the start, but there is a reasonable forward migration path that doesn't involve a complete auth rewrite going forward.
If I need to pay to access the enterprise features (just like with Auth0 or Cognito), why wouldn’t I just use those?
More customizability, benefit from the open core model, an easier on-ramp to try out and get used to the product.
Funny, I actually wrote a relatively simple auth system that does meet NIST guidelines (by default) and some other security requirements. It sends a JWT token for application usage and can register multiple applications for support, not full OAuth etc. The main application it's used with also integrates into other third party apps, so needed a simple means in-app for auth.
I tried to get permission to develop/publish this application as open-source, but was never able to do so. It's now got a few rough edges only because without the public need/perception some bits aren't as well flushed out beyond our internal use/needs and or the needs of our deployed instances. Not to mention a few requirements to satisfy a difficult architect/lead on another team, and they wound up not using the app anyway.
It's not too hard to meet some guidelines... I wound up using a simple KV pattern for data storage so I could target different adapters, add overlays for caching and encryption etc. There's some cool bits and some muddled bits.
I tried to get permission to develop/publish this application as open-source, but was never able to do so. It's now got a few rough edges only because without the public need/perception some bits aren't as well flushed out beyond our internal use/needs and or the needs of our deployed instances. Not to mention a few requirements to satisfy a difficult architect/lead on another team, and they wound up not using the app anyway.
It's not too hard to meet some guidelines... I wound up using a simple KV pattern for data storage so I could target different adapters, add overlays for caching and encryption etc. There's some cool bits and some muddled bits.
I would absolutely consider this once email verification exists for new accounts. But not until then.
It looks like a good feature set and yes, I would love to use a solution from someone who focuses on auth vs. rolling my own.
I do think your documentation could be expanded. You have some examples of how to use it with Netlify, but I'd love to see example apps for other cloud providers as well (Heroku, in my case.) Similarly for the react-auth documentation - the basic syntax of how to use it is a good start, but a full working app demonstrating its use with role-based authorizations would put it over the top to prove to me it could meet my needs.
It looks like a good feature set and yes, I would love to use a solution from someone who focuses on auth vs. rolling my own.
I do think your documentation could be expanded. You have some examples of how to use it with Netlify, but I'd love to see example apps for other cloud providers as well (Heroku, in my case.) Similarly for the react-auth documentation - the basic syntax of how to use it is a good start, but a full working app demonstrating its use with role-based authorizations would put it over the top to prove to me it could meet my needs.
Thanks for the valuable suggestions! Email verification is next on our list of features. We plan on providing an "active" method which requires you to verify the email to sign up, and one "passive" method which reminds you to verify the email from time to time post sign up (similar to many social networking sites).
For what it's worth I think email verification functionality would make me more keen to use a service like this!
Thats worth a lot! Would you mind sharing your email ID or ping me on: advait at supertokens [dot] io? I'll drop you an email as soon as we have it built
Do you have a uservoice page or issues on github where we could vote in support of a feature like this?
I know "me too" comments might not be the most helpful but... this sounds like the only blocker for me too!
I know "me too" comments might not be the most helpful but... this sounds like the only blocker for me too!
We don't have that unfortunately. However, a quick hack is to upvote an issue related to the feature you like the most, or create an issue in case it does not exist.
But thanks for the idea! It's a great one.. will have a look at it.
But thanks for the idea! It's a great one.. will have a look at it.
If email (or another mode of ) verification was added I'd be entirely on board for my next project (still in planning stage)
Thank you MH15! Its clearly top of the list for many people and it will be out before you need to build auth for your next project :)
Firebase Auth. One and done.
Can confirm. Just built out a little react MVP using firebase. Auth took mere minutes.
I've been using Nhost backend plus in a project and it has email verification for new accounts: https://github.com/nhost/hasura-backend-plus
Ory (https://www.ory.sh) seems to have similar aims, could you contrast? Did you consider their existing code?
If you are so inclined also interested in any comparison with https://keratin.tech/ and https://www.keycloak.org
If you are so inclined also interested in any comparison with https://keratin.tech/ and https://www.keycloak.org
It's always great to see new companies trying to improve on this problem. I'm the CEO of FusionAuth and we've been working on our product for 6 years now. I can attest to the complexity and challenges that exist in this industry. Our belief is that no one should be building auth anymore.
You should connect with Mike over at Gluu. He's a great guy and very supportive of the industry as a whole. I'm also happy to connect with you all as well.
Steer clear of Auth0, OneLogin and the others. They don't play fair and I'm positive you'll be receiving your first cease and desist letters in the coming weeks. We have stacks of them and their claims are always total BS. But you don't want to go to battle with a company that has $300M in the bank.
Congrats on the launch!
You should connect with Mike over at Gluu. He's a great guy and very supportive of the industry as a whole. I'm also happy to connect with you all as well.
Steer clear of Auth0, OneLogin and the others. They don't play fair and I'm positive you'll be receiving your first cease and desist letters in the coming weeks. We have stacks of them and their claims are always total BS. But you don't want to go to battle with a company that has $300M in the bank.
Congrats on the launch!
You've done great stuff with FusionAuth! I ended up using ORY [0] at my startup as we had slightly different auth needs, but FusionAuth was a top contender.
It's strange to me that Auth0 has so much market dominance. Are they a case of VCs subsidizing a subpar product, combined with aggressive (and bordering on false) marketing, or do they really have some unique product? Their pricing seems ridiculous to me; I can't imagine someone doing an analysis between Auth0 and alternatives, and choosing Auth0.
But seeing Atlassian switch to them made me think I may be missing something... It would be interesting to hear your analysis of why Auth0 is so prevalent!
[0]: https://www.ory.sh/
It's strange to me that Auth0 has so much market dominance. Are they a case of VCs subsidizing a subpar product, combined with aggressive (and bordering on false) marketing, or do they really have some unique product? Their pricing seems ridiculous to me; I can't imagine someone doing an analysis between Auth0 and alternatives, and choosing Auth0.
But seeing Atlassian switch to them made me think I may be missing something... It would be interesting to hear your analysis of why Auth0 is so prevalent!
[0]: https://www.ory.sh/
Woah, it sounds really shady... Could you share what those claims were about?
Wow, that pricing is awesome. Once you have email verification, social login, and a C# SDK, I will switch away from Auth0 in a heartbeat.
This being open source is a HUGE draw. It means I don't have to trust you as much, because the code is out in the open for security researchers to poke at. Do you have a bug bounty program?
I assume this works via an API as well, not just web based sessions? My use case is an online multiplayer game written in Unity.
This being open source is a HUGE draw. It means I don't have to trust you as much, because the code is out in the open for security researchers to poke at. Do you have a bug bounty program?
I assume this works via an API as well, not just web based sessions? My use case is an online multiplayer game written in Unity.
Email verification and social login is what we are currently working on. But C# isnt a common request at the moment. We'll definitely try to get to it asap. If you are interested, you could contribute the C# SDK together with us.
We do not currently have a bug bounty program.
You can use functions exposed via our SDK to verify & refresh a session yourself in your APIs - if that is what you were asking? Apologies if I misunderstood.
We do not currently have a bug bounty program.
You can use functions exposed via our SDK to verify & refresh a session yourself in your APIs - if that is what you were asking? Apologies if I misunderstood.
Any reason why you didn't use identityserver to host it yourselve?
You can have all of the things you're looking for with IdentityServer4. No need to wait!
I agree that auth is still a damn pain in the ass.
My last two experiences have been with Firebase and Django, both with React front-ends.
I think the state of JWT auth in Django with Rest Framework is dire. I've used the most popular packages (dj-rest-auth, which uses simple-jwt for JWT under the hood) and I've had to tweak way more than I would like to make it all work. I've been shocked to learn that this is not a solved problem in one of the world's most popular web frameworks, and I'd definitely consider using external auth in future projects.
The Firebase experience on the other hand has been outstanding. The front-end SDK is great and so is the documentation. I had to implement SAML SSO for a massive corporate customer using Microsoft AD and was able pull it off in an afternoon without a hitch. The ability to add custom claims and the like is also great - the whole thing feels really feature-complete. But then there's the fact that I don't trust Google with my user data and that I fear that at any time they could start charging onerous amounts for the service, or worse.
In both cases, the most painful bit however has been by far implementing the React front-end. Wiring the views, Redux async actions, etc. That's the part I wish I could get rid of. I see you provide some sort of front-end, but if you provided some sort of adjacent, standalone React library offering views and auth state management out of the box you'd surely get my attention - I'd possibly consider contributing code to it, too.
Overall I think the whole idea sounds great and you may be on to something: in summary, I feel that Google can't be trusted, Auth0 looks eye-watering expensive, Keycloak looks a bit complicated for certain projects, and popular web frameworks like Django may not be as good at token auth as we would take for granted.
I must be honest in that I wouldn't put your tech into production right now because I'm never a tech early-adopter, but I'll keep an eye on it, I'll seriously consider it for personal projects, and if it gets decent momentum in a few months I'll definitely consider extending it to client projects.
Congratulations for launching - I really, really wish you the best of luck.
My last two experiences have been with Firebase and Django, both with React front-ends.
I think the state of JWT auth in Django with Rest Framework is dire. I've used the most popular packages (dj-rest-auth, which uses simple-jwt for JWT under the hood) and I've had to tweak way more than I would like to make it all work. I've been shocked to learn that this is not a solved problem in one of the world's most popular web frameworks, and I'd definitely consider using external auth in future projects.
The Firebase experience on the other hand has been outstanding. The front-end SDK is great and so is the documentation. I had to implement SAML SSO for a massive corporate customer using Microsoft AD and was able pull it off in an afternoon without a hitch. The ability to add custom claims and the like is also great - the whole thing feels really feature-complete. But then there's the fact that I don't trust Google with my user data and that I fear that at any time they could start charging onerous amounts for the service, or worse.
In both cases, the most painful bit however has been by far implementing the React front-end. Wiring the views, Redux async actions, etc. That's the part I wish I could get rid of. I see you provide some sort of front-end, but if you provided some sort of adjacent, standalone React library offering views and auth state management out of the box you'd surely get my attention - I'd possibly consider contributing code to it, too.
Overall I think the whole idea sounds great and you may be on to something: in summary, I feel that Google can't be trusted, Auth0 looks eye-watering expensive, Keycloak looks a bit complicated for certain projects, and popular web frameworks like Django may not be as good at token auth as we would take for granted.
I must be honest in that I wouldn't put your tech into production right now because I'm never a tech early-adopter, but I'll keep an eye on it, I'll seriously consider it for personal projects, and if it gets decent momentum in a few months I'll definitely consider extending it to client projects.
Congratulations for launching - I really, really wish you the best of luck.
Which SDK/package did you use for Firebase and React? There seem to be half a dozen and ReactFire the most dated?
If you want a very basic implementation here’s a repo I made to hook the real-time db to react. Don’t know if it’s helpful for what you’re looking to do.
https://github.com/reidjs/react-firebase-input
https://github.com/reidjs/react-firebase-input
The official Google Firebase SDK... I didn't know there were third-party SDKs. All the React layer (views, state management, etc.) was my own.
Thanks
> But then there's the fact that I don't trust Google with my user data and that I fear that at any time they could start charging onerous amounts for the service, or worse.
What, Google would never do that :)
But seriously, I think that developer focused solutions are safer than other products, especially if they are tied to revenue and are fully established.
A quick scan of https://killedbygoogle.com/ shows a few dev focused products, but more consumer focused ones.
What, Google would never do that :)
But seriously, I think that developer focused solutions are safer than other products, especially if they are tied to revenue and are fully established.
A quick scan of https://killedbygoogle.com/ shows a few dev focused products, but more consumer focused ones.
Firebase auth itself is mostly free though - only phone-verified authentications are paid. I don't think they'd kill it but I wouldn't be surprised if they started charging on par with Auth0.
And if they're not charging for it, then what is the product? I mean, I know that they charge for other parts of the Firebase stack, but why offer a best-in-class authentication solution mostly for free?
And if they're not charging for it, then what is the product? I mean, I know that they charge for other parts of the Firebase stack, but why offer a best-in-class authentication solution mostly for free?
I would honestly question if you actually need JWT anyways.
jwt is useful for independently verified auth tokens. i.e. service a auths the user, generates a token that says ' this is definitely my user with this data'. service b can't auth the user because it has not access to the data, but can trust the jwt from service a.
every time i've seen someone with a jwt issue in django, they've just been wrapping the session id from django in a jwt, and then unwrapping it and verifying it in the db anyways.
jwt is useful for independently verified auth tokens. i.e. service a auths the user, generates a token that says ' this is definitely my user with this data'. service b can't auth the user because it has not access to the data, but can trust the jwt from service a.
every time i've seen someone with a jwt issue in django, they've just been wrapping the session id from django in a jwt, and then unwrapping it and verifying it in the db anyways.
I've read plenty about the limitations and security risks of JWT so I'll take the criticism in that sense. However I've implemented them a really hardened way (http-only cookies, not storing anything in localStorage, short token lives, revokable refresh tokens, etc.) so I'm pretty sure it'll be fine.
The thing is, I looked into other auth alternatives (sessions, regular tokens) for Django DRF + React and they all seemed just as difficult to implement. That's the sticking point in this whole discussion and what these guys are trying to solve - auth is critical and sensitive, but it's also largely a commodity that in most cases is not relevant to the application business logic, and there's no reason it should take so long to implement every. single. time.
(But if you have a tip on how to implement auth in Django + SPA's in a super-easy way that scales horizontally and allows users to stay logged in between sessions, I'm willing to be persuaded that the developer experience for auth doesn't suck so much)
The thing is, I looked into other auth alternatives (sessions, regular tokens) for Django DRF + React and they all seemed just as difficult to implement. That's the sticking point in this whole discussion and what these guys are trying to solve - auth is critical and sensitive, but it's also largely a commodity that in most cases is not relevant to the application business logic, and there's no reason it should take so long to implement every. single. time.
(But if you have a tip on how to implement auth in Django + SPA's in a super-easy way that scales horizontally and allows users to stay logged in between sessions, I'm willing to be persuaded that the developer experience for auth doesn't suck so much)
I'm definitely not questions if your doing things securely or not. Just if maybe needlessly complex.
I'll describe what i'm doing, as the code is kind of old.
* I have a token model that stores a uuid and the relevant user and data, along with an expiration. This isn't session data, just the valid token. You can also store this in redis or wherever.
* There is an endpoint that takes a username and password, and if valid, generates a token, and sets the token's id as a httpOnly secure cookie. This can also returns basic user data for display, name profilephotourl, global permissions, etc. This has a noauth decorator from DRF
* there is a check token endpoint which just returns the above data. This also updates the expiration.
* i have auth module based on rest_framework.authentication.BaseAuthentication that checks the cookie, token validity, etc and generates a valid user.
That's a high level overview.
I'll describe what i'm doing, as the code is kind of old.
* I have a token model that stores a uuid and the relevant user and data, along with an expiration. This isn't session data, just the valid token. You can also store this in redis or wherever.
* There is an endpoint that takes a username and password, and if valid, generates a token, and sets the token's id as a httpOnly secure cookie. This can also returns basic user data for display, name profilephotourl, global permissions, etc. This has a noauth decorator from DRF
* there is a check token endpoint which just returns the above data. This also updates the expiration.
* i have auth module based on rest_framework.authentication.BaseAuthentication that checks the cookie, token validity, etc and generates a valid user.
That's a high level overview.
on the front end i just hit that check_token endpoint every five minutes or so.
I'm really not sure that a refresh token on the front end actually provides that much security.
Also, this is all just one way of doing it.
I'm really not sure that a refresh token on the front end actually provides that much security.
Also, this is all just one way of doing it.
We're talking about simplicity, but the solution you outline sounds to me at least as complex as what I implemented, if not more...
I installed two popular libs, tweaked some code in the back, rolled out my front-end, and came up with a robust solution. In my opinion, I wouldn't have saved any time implementing your proposed design if I understand it correctly (especially on the front-end), and I'm not sure about its overall robustness since I don't like at all the idea of periodically polling from the front-end to check the state of the token, as opposed to automatically attempting a refresh on certain response conditions. But that's just me...
Regardless, my original point is that one shouldn't be spending much time at all on a commodity feature like this. I wish I could've spent 80% of that time writing real business logic and interfaces.
> I'm really not sure that a refresh token on the front end actually provides that much security.
Compared to any other mechanism where tokens are revokable (ex: hitting the db), no, it doesn't provide additional security.
Compared to non-revokable tokens it provides loads of additional security, without compromising on UX... The refresh token allows for short access token lifetimes (I have them at ~5min, same as Google has on Firebase), while providing the possibility of keeping the user logged in for weeks and having a revokation mechanism if it all goes south.
I installed two popular libs, tweaked some code in the back, rolled out my front-end, and came up with a robust solution. In my opinion, I wouldn't have saved any time implementing your proposed design if I understand it correctly (especially on the front-end), and I'm not sure about its overall robustness since I don't like at all the idea of periodically polling from the front-end to check the state of the token, as opposed to automatically attempting a refresh on certain response conditions. But that's just me...
Regardless, my original point is that one shouldn't be spending much time at all on a commodity feature like this. I wish I could've spent 80% of that time writing real business logic and interfaces.
> I'm really not sure that a refresh token on the front end actually provides that much security.
Compared to any other mechanism where tokens are revokable (ex: hitting the db), no, it doesn't provide additional security.
Compared to non-revokable tokens it provides loads of additional security, without compromising on UX... The refresh token allows for short access token lifetimes (I have them at ~5min, same as Google has on Firebase), while providing the possibility of keeping the user logged in for weeks and having a revokation mechanism if it all goes south.
considering flask-login for a new project, should I consider firebase instead? I do like most parts of GCP
Would love to know what is preventing you from considering SuperTokens
totally agree with you re: django jwt. i actually migrated (back) to firebase auth after several afternoons spent debugging a brittle django auth implementation. i partly blame my own inexperience for that... but i see no reason to bother with django auth anymore as firebase has been rock solid with minimal intervention.
Eh... Don't blame your inexperience. I'm also new to Django but not to web dev, and it's been a pain the ass. I haven't been stuck with any Django aspects (great framework otherwise) but rather issues with the libraries.
In the end I think I will make it work, and robustly. So I don't want to diminish the work of all the open-source devs who have worked on those libraries; I count my lucky stars that they're available in the open and for free.
But it's been painful nonetheless, and I am shocked that a better and more streamlined dev experience is not available, especially in such a popular stack.
In the end I think I will make it work, and robustly. So I don't want to diminish the work of all the open-source devs who have worked on those libraries; I count my lucky stars that they're available in the open and for free.
But it's been painful nonetheless, and I am shocked that a better and more streamlined dev experience is not available, especially in such a popular stack.
If you remember what you had to tweak for Django JWT auth - please do share. It would be interesting to hear your experiences.
In terms of implementing the react frontend, this is a common complaint:
We do have a react SDK that provides React components for login / sign up UI and its one of our powerful differentiators. It also does not need redux since the login components can handle state easily within themselves. That being said, one possibility to use redux would be to check if the user is logged in or not. For that, we provide a function from the SDK that can be called (doesSessionExist) anywhere in your react app. Hopefully this gets your attention :) Either way, we'd love to hear from you on our Discord or on my email ID (search Advait on this thread).
Your summary is incredibly on point and is part of our core thesis! Thank you for your candid feedback (we are also already in production environments but I understand your hesitancy).
Thank you so much for the encouragement - it is highly appreciated!
In terms of implementing the react frontend, this is a common complaint:
We do have a react SDK that provides React components for login / sign up UI and its one of our powerful differentiators. It also does not need redux since the login components can handle state easily within themselves. That being said, one possibility to use redux would be to check if the user is logged in or not. For that, we provide a function from the SDK that can be called (doesSessionExist) anywhere in your react app. Hopefully this gets your attention :) Either way, we'd love to hear from you on our Discord or on my email ID (search Advait on this thread).
Your summary is incredibly on point and is part of our core thesis! Thank you for your candid feedback (we are also already in production environments but I understand your hesitancy).
Thank you so much for the encouragement - it is highly appreciated!
Sure, dj-rest-auth + simple-jwt implements JWT with http-only cookies by default, which I have embraced. Except that when you refresh the token, it no longer returns and http-only cookie (it returns the access token in the response body) due to an issue with how the two aforementioned libs interoperate. So the dev has to patch that in manually with their own code, otherwise the full token cycle is not http-only. Isn't that weird?
Other issues include wiring some routes (urls, as Django calls them) so that they properly triggered password reset emails.
I want to insist that none of this has been the end of the world, and extend my eternal gratitude to the authors of the libs, but I guess I was shocked to encounter this in a framework as mature as Django (I've moved to it in search of stability compared to the Node.js ecosystem, which I feel is the wild west in some respects and not as suitable for the types of web apps I develop)
The other (more time-consuming) issues have been with implementing the front-end bits like I mentioned. An axios interceptor for refresh tokens, state management with Redux, the views (ugh, I love writing React but I really don't want to create another login form).
I'll definitely take a look at your React code tomorrow, and I may be able to provide some additional feedback (and maybe steal some ideas too)
Also, I want to commend your effort in marketing / comms - I've seen you both on Reddit and here, and this second impression on HN is what has prompted me to comment. Tbh first time I saw you on Reddit I thought this was more of a toy project but here on HN it's definitely clicked that you guys are serious.
I've starred you on Github, I'm watching for new releases, and I'll mention you to my friends, but I think you should definitely keep up your active communication efforts - it's worked for me at least.
Again, best of luck, and greetings from Spain!
Other issues include wiring some routes (urls, as Django calls them) so that they properly triggered password reset emails.
I want to insist that none of this has been the end of the world, and extend my eternal gratitude to the authors of the libs, but I guess I was shocked to encounter this in a framework as mature as Django (I've moved to it in search of stability compared to the Node.js ecosystem, which I feel is the wild west in some respects and not as suitable for the types of web apps I develop)
The other (more time-consuming) issues have been with implementing the front-end bits like I mentioned. An axios interceptor for refresh tokens, state management with Redux, the views (ugh, I love writing React but I really don't want to create another login form).
I'll definitely take a look at your React code tomorrow, and I may be able to provide some additional feedback (and maybe steal some ideas too)
Also, I want to commend your effort in marketing / comms - I've seen you both on Reddit and here, and this second impression on HN is what has prompted me to comment. Tbh first time I saw you on Reddit I thought this was more of a toy project but here on HN it's definitely clicked that you guys are serious.
I've starred you on Github, I'm watching for new releases, and I'll mention you to my friends, but I think you should definitely keep up your active communication efforts - it's worked for me at least.
Again, best of luck, and greetings from Spain!
Yes, that sounds pretty strange - thank you for sharing. Haha yes, it is surprising on the face of it. But when you think about it, its not trivial to make that everything is seamless for all use cases. It requires a lot of time and constant iteration and feedback. Being a maintainer is anyway not easy and when you have the entire framework to maintain, these things happen more often than not.
On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website).
Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io
Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)
On the frontend side, we have two libraries - supertokens-auth-react and supertokens-website. The supertokens-website repo deals with sessions (interceptors to axios for refresh + race condition synchronisation). On the other hand, supertokens-auth-react provides login / sign up UI + session management (it uses supertokens-website).
Thank you for the commendation! Would love to hear your feedback. Please do drop me an email on: advait at supertokens.io
Cuídate! (love Spain, have several friends and have visited barcelona, majorca, Sevilla and more)
Interesting idea! I did a quick look through your site and have a few issues:
1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection?
2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this?
3. Password reset emails come from @supertokens.io, which specifically raises phishing red flags when you get a password reset email from a domain that is not the one you're logging into. How would an integrator go about addressing this?
1. What MFA methods do you support? TOTP? App based auth? U2F? FIDO2? (FIDO2 USB? BLE? Platform authenticators?) Smart cards (especially for enterprise)? Backup OTP's? New device detection?
2. Your docs mention not playing nice with password manager autofill by default. Are there plans to address this?
3. Password reset emails come from @supertokens.io, which specifically raises phishing red flags when you get a password reset email from a domain that is not the one you're logging into. How would an integrator go about addressing this?
1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD.
2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead. The issue with that is that there might be CSS clashes and to prevent that, we use shadow-root (HTML feature). On certain browsers, password managers do not work with a shadow-root. So we provide a config that the user can set to disable the use of shadow-root. This would solve the password manager problem, but the developer will have to make sure that CSS does not clash.
3. This behaviour is the default one to quickly get started. We provide callbacks on the backend SDK that devs can override to send a password reset email using their own email ID domain.
2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead. The issue with that is that there might be CSS clashes and to prevent that, we use shadow-root (HTML feature). On certain browsers, password managers do not work with a shadow-root. So we provide a config that the user can set to disable the use of shadow-root. This would solve the password manager problem, but the developer will have to make sure that CSS does not clash.
3. This behaviour is the default one to quickly get started. We provide callbacks on the backend SDK that devs can override to send a password reset email using their own email ID domain.
> On certain browsers, password managers do not work with a shadow-root.
Eek. Worse than that, certain browsers (e.g. IE11) don't support Shadow DOM at all! You may wish to consider widening your browser support.
Eek. Worse than that, certain browsers (e.g. IE11) don't support Shadow DOM at all! You may wish to consider widening your browser support.
Oh! Thanks for the heads up! I have created an issue about this on our github, referencing this comment.
I second this! Please prioritize TOTP / U2F over social logins.
I might be off base here, but does anyone really leverage social logins anymore? Seems like it's the worst case scenario for auth in the case that a customer can no longer access the associated social account? Basically in every case you'd have to provide an antiquated flow for them to "re" sign-up with an email. I'm genuinely curious of the value add here, outside of using Sign In With Apple (since it parlays nicely into Apple Pay integrations).
I might be off base here, but does anyone really leverage social logins anymore? Seems like it's the worst case scenario for auth in the case that a customer can no longer access the associated social account? Basically in every case you'd have to provide an antiquated flow for them to "re" sign-up with an email. I'm genuinely curious of the value add here, outside of using Sign In With Apple (since it parlays nicely into Apple Pay integrations).
From our conversations with developers, a surprisingly large number of their users use social login - even when the site provides alternatives. Many have categorically said that they cant use any solution without social login. And we've seen this generally be true across many use cases
I always use social logins if I can, much easier for me and no password to remember (even if I use password manager). I think most people (non techie) use social login.
> I might be off base here, but does anyone really leverage social logins anymore?
I'm sure there are on tiktok and other popular social apps.
I'm sure there are on tiktok and other popular social apps.
We've been working on a project similar as supertokens, but does not mess with password manager and with TOTP and WebauthN support (Yubikey is tested).
The project really needs a great frontend. Right now it's mostly just a an API with all these features. It's also MIT licensed:
https://github.com/curveball/a12n-server
The project really needs a great frontend. Right now it's mostly just a an API with all these features. It's also MIT licensed:
https://github.com/curveball/a12n-server
Note that WebAuthn (the standardized replacement for U2F, you should not deploy U2F today) is deliberately designed to authenticate to the site you're actually visiting. It is possible (but not necessarily in all browsers) to override this and authenticate to an iframe for example to allow a third party to authenticate but this creates yet a further problem to deal with:
Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.
Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.
But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.
And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.
Now you've got WebAuthn's anti-phishing protection for the actual login, but that protection extends no further. As the native authentication of a site (e.g. Google, GitHub, Facebook) that's fine. But for a third party helper that's a problem.
Say I intend to visit my hypothetical WebAuthn enabled bank. If I go to https://fake-bank.example/convincing-phishing-page/ there is no way for them to get my real-bank.example credentials. The browser vendor is responsible for making sure this is true.
But now suppose they use "Super Tokens" instead, and I protect my "Super Tokens" with WebAuthn. I go to https://fake-bank.example/convincing-phishing-page/ and the bad guys who run it only need to fool "Super Tokens" into giving them a working token for my real bank. I authenticate with WebAuthn to Super Tokens and so that's working fine, but any flaws in the Super Tokens backend or implementation, out of my control, put me at risk. Not great news.
And this has already happened (as proof of concept anyway), to existing players in the space. It's categorically less safe to do this.
This would only be a threat if you're using the SaaS, right? If you self-host the user is still authenticating directly with your services, it's just that your services run a pre-made solution on the backend.
I hear you. The need for something simple is real.
I don't have a complex SSO/Auth need, and so, something as simple as single-factor FIDO based passwordless login (such as sawo [0] / portier [1]) or hands-off user management (like userbase [2] / human-id [3]) cuts it for me.
That said, the only question I have is the GitHub page says SuperTokens is "open core"
> SuperTokens is an open core alternative to proprietary login providers like Auth0 or AWS Cognito. We are different because we offer:
> - Open source:...
...So, which parts of supertokens is open core vs open source (supertokens-core, I can see, is vanilla Apache v2 without any strings attached like the horrible Commons Clause)?
[0] https://sawolabs.com/
[1] https://portier.github.io/
[2] https://userbase.com/
[3] https://human-id.org/
I don't have a complex SSO/Auth need, and so, something as simple as single-factor FIDO based passwordless login (such as sawo [0] / portier [1]) or hands-off user management (like userbase [2] / human-id [3]) cuts it for me.
That said, the only question I have is the GitHub page says SuperTokens is "open core"
> SuperTokens is an open core alternative to proprietary login providers like Auth0 or AWS Cognito. We are different because we offer:
> - Open source:...
...So, which parts of supertokens is open core vs open source (supertokens-core, I can see, is vanilla Apache v2 without any strings attached like the horrible Commons Clause)?
[0] https://sawolabs.com/
[1] https://portier.github.io/
[2] https://userbase.com/
[3] https://human-id.org/
Everything we have today is open source. However, in the future, we plan to monetize features that would be required by enterprises. At that point, we'd be an open core company where a large part of the software would be open source but a few features would be proprietary.
> We think that Auth0, Firebase etc are great services but auth is complex.
Yep that tends to happen when you are supporting SSO and certifications like OpenID Connect. Using one SSO portal to handle mobile, spa, web apps and code auth with evolving techniques like PCRE. That's probably why some customisations are not available too because it breaks the standard. You will just end up with the same models once you've implemented all the same features. Okta, Auth0 and others are all really similar because of the standards behind them not because they thrive to be complex.
Yep that tends to happen when you are supporting SSO and certifications like OpenID Connect. Using one SSO portal to handle mobile, spa, web apps and code auth with evolving techniques like PCRE. That's probably why some customisations are not available too because it breaks the standard. You will just end up with the same models once you've implemented all the same features. Okta, Auth0 and others are all really similar because of the standards behind them not because they thrive to be complex.
Agreed that the standards make things complex. However, some of them, like OpenID connect are not required for several apps that want just simple email password login (an example). This is where our idea of modules (or recipes) come from. If you choose a module which has nothing to do with OpenID connection (or similar spec), then you do not have to deal with it's complexity.
So essentially the way we hope to solve this problem is through our modular architecture. You can start off simple and then just keep adding the modules you need instead of it all rolled into one implementation
So essentially the way we hope to solve this problem is through our modular architecture. You can start off simple and then just keep adding the modules you need instead of it all rolled into one implementation
Authentication is a solved problem; authorization is not. External authentication makes your system brittle, so I'm glad to see you can self-host SuperTokens for free.
I've been working on Enterprise Access Control (EACL) in my spare time, an embedded Datalog-based library with a uniform declarative Clojure API that lets you write grant/deny ACL rules in the shape: Who, What, Why, When, Where & How that goes a little further than Role & Attribute. Link: https://github.com/theronic/eacl
Will do a Show HN when I fix all the bugs and get it fast enough.
Tokens are an interesting approach to future-proof a young application against having to rebuild auth internally. I like your up-front Pricing Philosophy section.
I've been working on Enterprise Access Control (EACL) in my spare time, an embedded Datalog-based library with a uniform declarative Clojure API that lets you write grant/deny ACL rules in the shape: Who, What, Why, When, Where & How that goes a little further than Role & Attribute. Link: https://github.com/theronic/eacl
Will do a Show HN when I fix all the bugs and get it fast enough.
Tokens are an interesting approach to future-proof a young application against having to rebuild auth internally. I like your up-front Pricing Philosophy section.
Worth to mention in the same area regarding authorization engine with APIs is OPA [1] which is relying on a Datalog inspired language: Rego.
I agree with you that authorization is lacking a set of standards allowing interoperability. The only known practical one XACML, has not seen wide adoption. OPA through its design and API allow useful feature for Enterprise use cases for which Styra [2] (founder of OPA) is selling a solution based on those APIs.
Note: I am not affiliated with Styra in any way.
[1] https://www.openpolicyagent.org
[2] https://www.styra.com/
I agree with you that authorization is lacking a set of standards allowing interoperability. The only known practical one XACML, has not seen wide adoption. OPA through its design and API allow useful feature for Enterprise use cases for which Styra [2] (founder of OPA) is selling a solution based on those APIs.
Note: I am not affiliated with Styra in any way.
[1] https://www.openpolicyagent.org
[2] https://www.styra.com/
> is a solved problem
This expression is idly thrown about nowadays. It implies that a solution exists and can't be further improved upon. Just because a solution exists, or is the current fashion, doesn't mean it's a 'solved problem'. Beer brewing is a 'solved problem'.. yet there are some brews you couldn't pay me to drink. Interesting problems are never fully solved, they are simply iterated on over and over. Payment processing was a 'solved problem' until Stripe came along. Assembly line manufacturing of cars was a 'solved problem' until Toyota showed Ford how it could be done better.
This expression is idly thrown about nowadays. It implies that a solution exists and can't be further improved upon. Just because a solution exists, or is the current fashion, doesn't mean it's a 'solved problem'. Beer brewing is a 'solved problem'.. yet there are some brews you couldn't pay me to drink. Interesting problems are never fully solved, they are simply iterated on over and over. Payment processing was a 'solved problem' until Stripe came along. Assembly line manufacturing of cars was a 'solved problem' until Toyota showed Ford how it could be done better.
Cue Zed Shaw and "The ACL Is Dead"...
I once worked on a project for flexible authorization called "SecureKit" which attempted to be a common criteria evaluated system for any kind of authorization. It quickly became apparent that it would pretty much have to be Turing complete to satisfy the general case.
For example, some systems anyone can authenticate when a fire is occurring in some other areas, but normally only a certain set of people can have access to it.
I once worked on a project for flexible authorization called "SecureKit" which attempted to be a common criteria evaluated system for any kind of authorization. It quickly became apparent that it would pretty much have to be Turing complete to satisfy the general case.
For example, some systems anyone can authenticate when a fire is occurring in some other areas, but normally only a certain set of people can have access to it.
Yes, this is what I realized too. It is why EACL is embedded in the application layer instead of trying to run in a layer above it. To do authorization properly, rules need to be embedded alongside the secured data and decision code needs to run next to application code.
Authentication is not a solved problem. Every ecommerce website out there rolls their own, usually with obvious flaws. Some major banks too.
We’re using Keycloak.org which is a great product, easy to use, a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect from modern user authentication and management system. You should check that out, user auth is indeed a solved problem.
Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak:
We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity.
We provide far more flexibility and options on the frontend as well
KeyCloak is a small part of the Redhat (and even less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).
Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.
We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.
Finally - in general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one. I understand that this was not true for you.
If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity.
We provide far more flexibility and options on the frontend as well
KeyCloak is a small part of the Redhat (and even less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).
Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.
We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.
Finally - in general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one. I understand that this was not true for you.
If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
Is SuperTokens multitenant capable? My understanding is that keycloak suffers in a multitenant enviroment with a sufficiently high number of tenants.
I had the same question - apparently the answer is yes: https://supertokens.io/docs/emailpassword/common-customizati...
To an extent, yes: https://supertokens.io/docs/emailpassword/common-customizati...
Typical multi tenancy implies that the auth experience and data is isolated per tenant. However, often b2b companies simply want to provide an auth experience to their client within a specific subdomain. They do not mind the auth data be stored in the same db tables as other clients. If this is the use case, then we do support it. If you want strict isolation of auth per tenant, then you will have to deploy multiple instances of the SuperTokens core (as of today).
Typical multi tenancy implies that the auth experience and data is isolated per tenant. However, often b2b companies simply want to provide an auth experience to their client within a specific subdomain. They do not mind the auth data be stored in the same db tables as other clients. If this is the use case, then we do support it. If you want strict isolation of auth per tenant, then you will have to deploy multiple instances of the SuperTokens core (as of today).
I'm also curious about multi-tenancy.
Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?
Can I store users in per-tenant databases? Maybe if I forked the stroage plugin and modified it to do that?
How about keycloak-gatekeeper? Do you offer something similar?
[deleted]
I cannot imagine building auth into a system now without using Keycloak.
It's a comprehensive platform for sure, which makes for some pretty intense concepts and documentation.
But once you lay your hands on a suitable tutorial it's dead easy to get running, and you'll never find yourself stuck when some PHB asks you about your password rotation policies, 2 factor auth, SAML, SSO etc. etc. Keycloak does everything you could ever want for auth.
It's a comprehensive platform for sure, which makes for some pretty intense concepts and documentation.
But once you lay your hands on a suitable tutorial it's dead easy to get running, and you'll never find yourself stuck when some PHB asks you about your password rotation policies, 2 factor auth, SAML, SSO etc. etc. Keycloak does everything you could ever want for auth.
I think Keycloak is very complicated. Lots of things to learn. It is like a space shuttle with lots of settings.
Keycloak is great software, and I am thankful to Redhat for keeping it open source and maintaining it. But I do not believe that a production deployment of keycloak with HA, backups, customization, integrations, upgrades etc. is easy at all. It takes time and planning to get it right. Depending on the constraints, it isn't obvious to me why it would win by default over SaaS alternatives, or simpler on-premises alternatives like OP's.
> HA, backups, customization, integrations, upgrades etc
I confirm that, we had a bunch of problems with upgrades in one product. In long term keycloak introduced more headaches for ops than we devs had implementing integrations with auth0 or okta. That was before KC10.
I confirm that, we had a bunch of problems with upgrades in one product. In long term keycloak introduced more headaches for ops than we devs had implementing integrations with auth0 or okta. That was before KC10.
Curious what sorts of headaches there were in this. We're currently in the process of implementing KC12 using the docker image, a User Storage SPI (our users exist in our legacy master database which is synced from an external billing system), and it's looking so far like it'll be a fairly simple setup. This is basically just acting as a OAuth shim between our primary database and an external service provider in our case, which I imagine keeps the complexity down. But I'm wondering what you might have run into that we haven't yet. Thanks!
Keycloak feels a bit like a nuclear power plant control panel to me, so I'm happy to see an alternative like this pop up.
I would be careful depending on Keycloak given what happened with CentOS recently:
- https://www.gluu.org/blog/keycloak-is-the-next-centos/
- https://www.gluu.org/blog/keycloak-is-the-next-centos/
I hope IBM/Red Hat have more sense than this, but time will tell. It may not make sense for them to maintain Keycloak with all of IBMs identity solutions.
> a lot of functionality (if you want to), deplorable “on-premise” and does offer everything what you expect
Baseod on the rest of your comment, I think maybe deplorable was not the word you intended to use there?
Baseod on the rest of your comment, I think maybe deplorable was not the word you intended to use there?
Keycloak is not my favorite thing - it's unnecessarily esoteric and complicated IMO - but I agree it does do pretty much what this is listening.
It's like you're speaking directly to me. The only thing I ever use Firebase for is auth and it's cumbersome and annoying. I'm excited to try this. Thank you for having a sensible free tier.
I'm a devops/support engineer and I build out small tools all of the time for our teams and I use Firebase for auth as an end-around our IT admin to avoid having to request oauth2 apps via Google every time I need to make something, since all of our people share the same e-mail domain.
That's what I'd be looking to do with your product. I've got a project in mind to give it a shot.
I'm a devops/support engineer and I build out small tools all of the time for our teams and I use Firebase for auth as an end-around our IT admin to avoid having to request oauth2 apps via Google every time I need to make something, since all of our people share the same e-mail domain.
That's what I'd be looking to do with your product. I've got a project in mind to give it a shot.
Thanks for the encouragement :) We will be happy to help when you get started.
Interesting. From reading the website briefly and the announcement above, this seems like a "super library".
If there's an auth spectrum, from:
roll your own -> use a language specific library -> use a full featured solution like Auth0, Firebase or FusionAuth
it seems like SuperTokens is in between the library and the full featured solution.
I guess I'd ask, if I don't want a full featured solution (the use case you've identified), why wouldn't I use a language specific library (devise for rails, passport for js, etc). Or is the value that you're providing a modular integration so I don't have to integrate authentication + authorization + user management + API auth myself?
Anyways, congrats on launching. We need more auth solutions and I'm glad to see an interesting approach in the open source world. The other major contender, KeyCloak, is, I've heard, a bear to run and extend.
Full disclosure, I'm an employee of FusionAuth.
If there's an auth spectrum, from:
roll your own -> use a language specific library -> use a full featured solution like Auth0, Firebase or FusionAuth
it seems like SuperTokens is in between the library and the full featured solution.
I guess I'd ask, if I don't want a full featured solution (the use case you've identified), why wouldn't I use a language specific library (devise for rails, passport for js, etc). Or is the value that you're providing a modular integration so I don't have to integrate authentication + authorization + user management + API auth myself?
Anyways, congrats on launching. We need more auth solutions and I'm glad to see an interesting approach in the open source world. The other major contender, KeyCloak, is, I've heard, a bear to run and extend.
Full disclosure, I'm an employee of FusionAuth.
Thanks for the comment and disclosure :)
We do intend to be a full featured solution. Though, since we are relatively new, we only provide email and password.
That being said, our approach is modular in nature so that users get only what they want.
We do intend to be a full featured solution. Though, since we are relatively new, we only provide email and password.
That being said, our approach is modular in nature so that users get only what they want.
So if you are aiming to be full featured, the modularity plus open source is your differentiator?
What are you going to do if AWS/GCP/Azure decides to offer a managed services version of your software? (I know, I know, that'd be a a great problem to have.)
What are you going to do if AWS/GCP/Azure decides to offer a managed services version of your software? (I know, I know, that'd be a a great problem to have.)
AWS etc. already offer these services so the risk is low. I dislike the recent trend of companies changing licenses from a formerly FLOSS solution to "source available".
It prevents little in practice and makes it so that your original differentiator i.e. open source is no longer true.
It prevents little in practice and makes it so that your original differentiator i.e. open source is no longer true.
> AWS etc. already offer these services so the risk is low.
I'm not sure about that. AWS had a NoSQL database, but replicated mongodb.
Anyway, I think that the risk doesn't occur until and unless supertokens hits a home run. I mean, if you're big enough for a hypercloud provider to copy, that means you've been pretty darn successful in distribution of your product.
But the risk is there.
As for the relicensing, I have sympathy for both viewpoints. I posted this in a different comment, but this medium article does a good job of talking about both sides of the issue: https://joemorrison.medium.com/death-of-an-open-source-busin...
I'm not sure about that. AWS had a NoSQL database, but replicated mongodb.
Anyway, I think that the risk doesn't occur until and unless supertokens hits a home run. I mean, if you're big enough for a hypercloud provider to copy, that means you've been pretty darn successful in distribution of your product.
But the risk is there.
As for the relicensing, I have sympathy for both viewpoints. I posted this in a different comment, but this medium article does a good job of talking about both sides of the issue: https://joemorrison.medium.com/death-of-an-open-source-busin...
Congratulations on the launch! Innovation in the Auth* space is really necessary. How do you plan on differentiating from other open source solutions, such as https://github.com/ory/kratos or https://github.com/keycloak/keycloak?
Thank you! I answered a similar comment which it seems like you've seen. Not sure I understood your response on that one. Why was the tone deplorable?
I think you confused the threads :)
Oops, yes I did - haha.
But I hope it answered your question?
Also, when you say innovation is neccessary - what makes you say that? In the sense that do you have any specific pain points or innovation in mind?
But I hope it answered your question?
Also, when you say innovation is neccessary - what makes you say that? In the sense that do you have any specific pain points or innovation in mind?
Sick of spending your time on auth, you decided to spend all your time on it?
Haha we both did laugh at this one.
I mean we were sick of doing it when we trying to build a product whos core value prop was different because auth was a distraction. We wanted to focus. Now that we're focussing ON auth, we are happy to do it cause it is the core product
I mean we were sick of doing it when we trying to build a product whos core value prop was different because auth was a distraction. We wanted to focus. Now that we're focussing ON auth, we are happy to do it cause it is the core product
If a thing annoys you it'll probably annoy a lot of people that are probably willing to pay to solve the problem.
It annoys me for sure and which it were simpler. What I found when integrating SAML is you have to work with whatever login code you already have which will build in assumptions across your app.
Exactly
It's a pain point. It's always a good place to plant your flag.
Hi,
just FYI, I saw that you are setting third party cookies without consent. While I generally don't like the flood of cookie banners, it's a legal requirement if you are accepting EU customers.
just FYI, I saw that you are setting third party cookies without consent. While I generally don't like the flood of cookie banners, it's a legal requirement if you are accepting EU customers.
Thanks for the heads up!! We will fix this ASAP.
I'm really happy to see a service like this and I wish you the best of successes. BUT :) If you're going to call yourself the "Stripe of X", please work on reaching the bar they've set for documentation.
Thank you so much! Appreciate it.
Also, we agree - we have a lot to do before earn it (but also a fair comparison would be to Stripe's docs when they were new as opposed to today).
Also, we agree - we have a lot to do before earn it (but also a fair comparison would be to Stripe's docs when they were new as opposed to today).
Sounds like this may pair with something like OSO for Python (osohq.com), thanks! Do you plan to directly support language specific client libraries or are you looking for community support of that work?
Yea! Integrations with OSO makes sense! We do have plans to support language specific client libraries.
I got experience mainly with firebase and identity server. What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication?
I’m far from an expert, but in past startups I’ve been scrambling to get SSO working for b2b saas, they bluntly said. Without sso we don’t want to use your service. So that was moved up our roadmap.
Even something like e-mail verification is something I will not go without anymore. It’s mandatory in some countries.
Honestly, next service that I will build will just be federated or magic email link if I can get away with it.
From the frontpage I cannot understand yet what makes this easier then the options above. Is this something you would use for your first 3000 customers? Imagine being the cto, when would I feel confident going for something like supertoken?
Also, it’s easy to ask questions like this, less so than building amazing things, so definitely Congratulations on the announcement!
I’m far from an expert, but in past startups I’ve been scrambling to get SSO working for b2b saas, they bluntly said. Without sso we don’t want to use your service. So that was moved up our roadmap.
Even something like e-mail verification is something I will not go without anymore. It’s mandatory in some countries.
Honestly, next service that I will build will just be federated or magic email link if I can get away with it.
From the frontpage I cannot understand yet what makes this easier then the options above. Is this something you would use for your first 3000 customers? Imagine being the cto, when would I feel confident going for something like supertoken?
Also, it’s easy to ask questions like this, less so than building amazing things, so definitely Congratulations on the announcement!
Thanks for your comment :)
> What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication?
We plan on building a much more feature rich auth solution in a modular way - providing passwordless, 2fa, social, email / password login (exists already) + very secure session management using rotating refresh tokens (exists already). Being "modular" will enable users to only pick what they care about making it easy for them to implement. So we differentiate in terms of features and simplicity of use.
> Even something like e-mail verification is something I will not go without anymore. Makes sense! Next on our feature list
> Is this something you would use for your first 3000 customers? We aim that this would scale to a very large number of users - so you can implement it once, and then spend minimal time on it after.
> What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication?
We plan on building a much more feature rich auth solution in a modular way - providing passwordless, 2fa, social, email / password login (exists already) + very secure session management using rotating refresh tokens (exists already). Being "modular" will enable users to only pick what they care about making it easy for them to implement. So we differentiate in terms of features and simplicity of use.
> Even something like e-mail verification is something I will not go without anymore. Makes sense! Next on our feature list
> Is this something you would use for your first 3000 customers? We aim that this would scale to a very large number of users - so you can implement it once, and then spend minimal time on it after.
+1 for SAML 2.0 SSO support. I see this gap a lot in early SaaS products, it's a must if your product wants to onboard enterprise customers.
I'm impressed and glad you chose a real Open Source license. I really hope you can make money off of this so it can remain free to use (and I think you can, judging by Auth0's customers)
Also, I assume you can add captchas as a custom theme. Could you add some sample code for that (and other user stories) in your docs/repos? In cases where somebody's got to implement something super quick, and there's a competitor who has really easy to follow docs, sometimes that alone can convert a customer.
The use cases we have for Cognito include: zero-trust authentication portals for services, enterprise SSO, customer portals for applications, session/user management. For Auth0, the same plus API management (including billing, authn+z, etc)
Also, I assume you can add captchas as a custom theme. Could you add some sample code for that (and other user stories) in your docs/repos? In cases where somebody's got to implement something super quick, and there's a competitor who has really easy to follow docs, sometimes that alone can convert a customer.
The use cases we have for Cognito include: zero-trust authentication portals for services, enterprise SSO, customer portals for applications, session/user management. For Auth0, the same plus API management (including billing, authn+z, etc)
Thank you for your encouragement!
Yes, themes are customizable and anyone can contribute one. Adding captchas is a good idea and I've added it to the list of themes we have in mind. We'll build out a theme with captchas! Regarding sample code on how to do it, please let me revert, will have a look at how captchas work and if easily doable, will add it shortly.
Your current use case for Cognito is beyond what we currently offer or plan to in the near future. However, we'd appreciate it if you follow along and consider SuperTokens for projects where we would be relevant.
Yes, themes are customizable and anyone can contribute one. Adding captchas is a good idea and I've added it to the list of themes we have in mind. We'll build out a theme with captchas! Regarding sample code on how to do it, please let me revert, will have a look at how captchas work and if easily doable, will add it shortly.
Your current use case for Cognito is beyond what we currently offer or plan to in the near future. However, we'd appreciate it if you follow along and consider SuperTokens for projects where we would be relevant.
Considering the number of problems that arise when someone confuses "authentication" with "authorization", it makes me slightly queasy to see something claim a focus on "auth". :/
Hahahaha. Fair enough. And it get's even worse when talking about sessions and tokens...
As somebody who has never liked implementing login, and I've had some friends who have tried similar start-ups to yours in the past.
Who are your customers that are not using one of the cloud providers and want to use an open-source 3rd party? With all my stuff on AWS or Firebase/GCloud, it somewhat just makes sense to use their authentication.
Are there cloud competitors you can partner with?
I do disagree with the idea that Firebase or Cognito auth are complex. If you're able to build the rest of the cloud service, you're able to build on that.
Who are your customers that are not using one of the cloud providers and want to use an open-source 3rd party? With all my stuff on AWS or Firebase/GCloud, it somewhat just makes sense to use their authentication.
Are there cloud competitors you can partner with?
I do disagree with the idea that Firebase or Cognito auth are complex. If you're able to build the rest of the cloud service, you're able to build on that.
Great initiative! As someone who has worked on Auth systems multiple times, I can so much relate to it. In fact, at one of the jobs I created something quite generic (SSO by SSO, multiple token types, multiple interfaces (including OAuth), multiple password backends, email domain specific verification methods, etc. Wanted to open source it, but then given it was related to security and we were not really a security company, we let go of that plan.
All the best to you and your team!
All the best to you and your team!
Thats awesome! Thank you
I had to scroll thru the website, find docs then click thru to the quick start to discover that this is nodejs. Put the tech used on the front page.
You may want to hold back the "Stripe for Auth" tagline until you have more languages implemented. Also you aren't competing with things like Auth0 because if an organization has money for Auth0 why would they roll their own? You are competing with all the different open source framework implementations for Auth.
You may want to hold back the "Stripe for Auth" tagline until you have more languages implemented. Also you aren't competing with things like Auth0 because if an organization has money for Auth0 why would they roll their own? You are competing with all the different open source framework implementations for Auth.
[deleted]
We have a line under the first login GIF that says "Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon". Apologies if this was not evident enough. Will factor this feedback into our UI design process.
Certainly, we arent there yet but Stripe for Auth is where we want to be. Based on our experience, we actually do compete with all the proprietary services as well and not just the open source frameworks. When someone (who "has money") is looking for an auth solution, they dont look at which solution is paid. They look at which solution is best for them and that can be either open source, freemium, paid - whatever.
Certainly, we arent there yet but Stripe for Auth is where we want to be. Based on our experience, we actually do compete with all the proprietary services as well and not just the open source frameworks. When someone (who "has money") is looking for an auth solution, they dont look at which solution is paid. They look at which solution is best for them and that can be either open source, freemium, paid - whatever.
Hey Advait! Glad to see your work here man :) Will be watching the project closely over the next year. Having recently re-built authn + authz using Cognito (we evaluated Auth0 and building it ourselves as well) I can confidently agree that doing auth right is hard and complex. Especially once you get into social providers, keeping identities synced, MFA, etc. Excited to see where the project lands!
Thank you Ashwin! Yes, that is the plan. WOuld love to hear your experiences using Cognito!
This is really cool. Thanks for making it.
Thinking on how I would use it, I appreciate free tier, but I think once things get more involved, I might actually do self hosting, which leaves you without income.
I would see about that, otherwise it is cool. If you can't make money, then just when we start using it, you might decide this is not worth pursuing and it wouldn't be good for everyone.
Wish you the best.
Thinking on how I would use it, I appreciate free tier, but I think once things get more involved, I might actually do self hosting, which leaves you without income.
I would see about that, otherwise it is cool. If you can't make money, then just when we start using it, you might decide this is not worth pursuing and it wouldn't be good for everyone.
Wish you the best.
Thank you for the encouragement, we appreciate it!
We are happy with developers and early stage startups using SuperTokens for free. Our plan is to monetize feature that are required by enterprises. We have a philosophy section in the pricing page that explains this is more details
We are happy with developers and early stage startups using SuperTokens for free. Our plan is to monetize feature that are required by enterprises. We have a philosophy section in the pricing page that explains this is more details
Hey, this product looks like a pretty decent "stack agnostic" way to handle auth. I've definitely considered using services like Cognito but always returned to "DIY" for the data ownership. A couple questions:
1. How will you keep bigger engineering teams on your platform if access to the data (and therefore migration) is easy?
2. I mainly work with Python. Typically I use Django's user system with my own user model and I copy and paste the client company's "general email template" into the verification / signup / reset emails and I'm done with it. If I need it on multiple services I install a JWT plugin. It takes maybe 10 minutes at the start of a project, and the developer experience is similar from what I have heard in Rails with Devise. Does this service have anything to offer to these "mature" stacks, or are you generally targeting newer ecosystems like Node / "frontend first" projects?
Also, your landing page looks great!! :)
1. How will you keep bigger engineering teams on your platform if access to the data (and therefore migration) is easy?
2. I mainly work with Python. Typically I use Django's user system with my own user model and I copy and paste the client company's "general email template" into the verification / signup / reset emails and I'm done with it. If I need it on multiple services I install a JWT plugin. It takes maybe 10 minutes at the start of a project, and the developer experience is similar from what I have heard in Rails with Devise. Does this service have anything to offer to these "mature" stacks, or are you generally targeting newer ecosystems like Node / "frontend first" projects?
Also, your landing page looks great!! :)
Thank you!
1. Developers should not be forced to stay with us because they cant leave. The mindset is that the customer is always first and if they find a better solution than our job is to be better than that alternative (not prevent them from going).
2. SuperTokens works primarily with NodeJS at the moment, but we planning on supporting more frameworks like Django. We offer session management (i.e. securely handling of tokens) for the more "mature" stacks since that was what we originally started off with. Once we have traction for one language, we will expand into other ones that users are requesting
1. Developers should not be forced to stay with us because they cant leave. The mindset is that the customer is always first and if they find a better solution than our job is to be better than that alternative (not prevent them from going).
2. SuperTokens works primarily with NodeJS at the moment, but we planning on supporting more frameworks like Django. We offer session management (i.e. securely handling of tokens) for the more "mature" stacks since that was what we originally started off with. Once we have traction for one language, we will expand into other ones that users are requesting
Getting Django would be amazing, speaking as a user for whom Keycloak was interesting except not trusting IBM/RedHat as safe & responsible stewards. And we're exactly in that market of 'we want the OSS + on-prem friendly variant for our on-prem users, but a managed service provider for our managed tier.' Auth0 and friends show how big this market is, and the general push to SaaS-only by them and their competitors has been a non-starter. Smart!
Unfortunately the focus on nodejs / non-django backends means we won't be evaluating for now -- despite being actively looking at this space. But if you or others become active here, am interested. See replicated.com -- implementing API tokens, RBAC, etc. is necessary for teams like ours yet largely generic, so a good OSS-native partner to pick up where frameworks like Django fall down would be awesome. Good luck!
Unfortunately the focus on nodejs / non-django backends means we won't be evaluating for now -- despite being actively looking at this space. But if you or others become active here, am interested. See replicated.com -- implementing API tokens, RBAC, etc. is necessary for teams like ours yet largely generic, so a good OSS-native partner to pick up where frameworks like Django fall down would be awesome. Good luck!
We plan on adding Django support asap. If you could share your email ID or drop me an email at advait at supertokens.io - I will update you as soon as we have the Django SDK ready
Reminds me of when I was working at the exact same kind of startup and then AWS Cognito got SAML support. I'm not exactly sure what that startup's business model actually was or what yours could be, they got acquihired and enough to pay back the VCs though.
Auth really didn't get better since then?
Auth really didn't get better since then?
We're bias but we obviously dont think so. Infact, we think its gotten more complicated over the years. Some of that complexity is for the right reasons but that isnt required for everyone and for all use cases
Honestly, Auth0 is cancer for startups and artificially increases the cost of every user.
I Really hate Auth0; you should, too.
I Really hate Auth0; you should, too.
[deleted]
The pricing model is completely unreasonable. I'll never use or recommend it to anyone.
This looks very cool and I could use it but I would be more happy for an EU version of this where I can simply pay you for hosting it for me, at least until I know my app or project is successful. I think there is a room for a Plausible version of auth. I think it's good that you offer to self-host it but honestly that is a bit of work as well.
I use a js-only backend so installing Java as a dependency maybe isn't the biggst deal but it's still something I will have to consider.
Even if it's more work to configure and setup an auth myself I will know the intimate details of how it works and don't have to spend time learning another tool in another language. Both takes time and since I've implemented auth several times already it isn't that big of a deal for me.
I use a js-only backend so installing Java as a dependency maybe isn't the biggst deal but it's still something I will have to consider.
Even if it's more work to configure and setup an auth myself I will know the intimate details of how it works and don't have to spend time learning another tool in another language. Both takes time and since I've implemented auth several times already it isn't that big of a deal for me.
You wouldnt need to install your own JDK. We package it all nicely in a docker container so you do not have to worry about it. This makes running SuperTokens just like running any other http microservice.
But yes, your point is valid. If you'd like to be able to know the intimate details and make modifications (that we dont offer), then this would hold true. But all in all, the reasons we picked java were:
Java has a very mature ecosystem. This implies that third party libraries have been battled tested. It's strong type system ensures fewer bugs and easier maintainability. This is especially important when many people are expected to work on the same project (for open source).
But yes, your point is valid. If you'd like to be able to know the intimate details and make modifications (that we dont offer), then this would hold true. But all in all, the reasons we picked java were:
Java has a very mature ecosystem. This implies that third party libraries have been battled tested. It's strong type system ensures fewer bugs and easier maintainability. This is especially important when many people are expected to work on the same project (for open source).
Well, I don't really use docker for my own stuff so installing it to simply use a third party application seems harder than simply installing the software required.
I am not questioning your choice of language. It's all fine and dandy I am just questioning myself and if I have enough willpower to actually host it myself. :)
I am not questioning your choice of language. It's all fine and dandy I am just questioning myself and if I have enough willpower to actually host it myself. :)
Not the same thing, as I'm only ever being the Auth client, but I use the approach I documented at https://github.com/forbesmyester/esqlate/issues/5#issuecomme... .
The nice thing about this is that everything behind the NGINX load balancer you don't have to worry about the users being authenticated and / or not.
If you need roles / permissions / metadata you can roll that into your one piece of software which handles the client side auth.
For something small scale, it's perfectly viable to run it all in a `docker-compose`... For something bigger, I've been hosting it on K8s.
The nice thing about this is that everything behind the NGINX load balancer you don't have to worry about the users being authenticated and / or not.
If you need roles / permissions / metadata you can roll that into your one piece of software which handles the client side auth.
For something small scale, it's perfectly viable to run it all in a `docker-compose`... For something bigger, I've been hosting it on K8s.
I really appreciate that you offer your SaaS version for free up to 5K monthly active users! That's high enough that I can actually use this for a side project... $30/mo for the next 5k seems fine. I also appreciate that it's active users.
For comparison, Auth0 also charges for active users, but 10k MAUs would put you at $228.
I know some established companies and well-funded startups can pay that without batting an eye, but it seems non-viable for a lot of projects.
I know some established companies and well-funded startups can pay that without batting an eye, but it seems non-viable for a lot of projects.
Thats great to hear. We'd love to help you get started with your side project. Feel free to ping us on Discord or on my email ID advait at supertokens [dot] io for any help you need!
How does this compare to something like Dex or Ory?
From an SDK approach you might want to start with a generic language library/sdk rather than a specific framework. In Python for example, I see a Flask implementation (cool) but wishing there was one for Django. You will get more miles out of a generic SDK per language, than can be used within framework specific implementations longer term. Less to support and less overhead to test.
SSO support is a hard requirement, so it's a pass from me. SSO is not an "enterprise" feature. It's a feature demanded by enterprises we sell to. It's also good security practice internally.
Is it fair to categorize the pitch here as "a simpler AWS Cognito"?
Simpler and open source AWS Cognito.
Don't forget that you can self host as well. That, for some use cases, is a simply killer feature.
This is an idea that I briefly pursued for the same reasons you list, namely that it's a ubiquitous problem which needs to be solved repeatedly.
But in a rough design sketch as to how I would create a generic solution, I made the auth service a proxy for the main app. So user data would be verified and decoded in the proxy, and the app could trust the passed token. This removes the need for a back end driver.
I'm curious about why you didn't choose this approach, and instead made the auth service callable from the app?
But in a rough design sketch as to how I would create a generic solution, I made the auth service a proxy for the main app. So user data would be verified and decoded in the proxy, and the app could trust the passed token. This removes the need for a back end driver.
I'm curious about why you didn't choose this approach, and instead made the auth service callable from the app?
This is a complicated decision to have made and perhaps a blog post is needed for this. But here is an attempt to answer it:
A complex enough app will require modifications to the auth flow. Most services achieve that via webhooks or by forcing devs to write code in their "dashboard". This code would then live outside the main codebase which is annoying. So we thought that if someone was making their own auth, they would want to have all their code in their backend API itself. The best way to allow that was to hide the auth server behind their API server (which is a proxy to the auth server for certain APIs like sign up / sign in etc..)
A complex enough app will require modifications to the auth flow. Most services achieve that via webhooks or by forcing devs to write code in their "dashboard". This code would then live outside the main codebase which is annoying. So we thought that if someone was making their own auth, they would want to have all their code in their backend API itself. The best way to allow that was to hide the auth server behind their API server (which is a proxy to the auth server for certain APIs like sign up / sign in etc..)
I suppose another upside is that you can do token validation in the app and not need to have proxy communication on every request.
Guys, why bother integrating different SDKs for different languages and for different IdPs. We provide an App Access Proxy which decouples authZ and authN from your apps and APIs. We integrate Auth0, Okta, Azure AD for you and you just need to put our lightweight container proxy in front of your apps. If you don't have too many apps, it's free for use! Checkout more details here. https://datawiza.com
I'm just in the process of setting up our Auth system now with cognito. It sure is painful! Looks like you guys have everything I need except social login.
We're building email verification and social login at the moment and would love to have it ready in time for you. When do you plan to launch your product by?
Hoping to launch in January
Do you mind sharing your email ID or dropping me an email at advait at supertokens.io? We should have it ready by Jan (and hopefully in time for you)
Congratulations on launch and good luck in a very crowded market. We are building something similar with focus on SaaS companies (https://axioms.io/). I really like your multi-tenancy approach - interesting take could be very useful for B2B SaaS companies. We achieve similar outcome using organizations.
Thank you! Best of luck :)
Well, here's the initial commit of RESTful Authentication library from 2006: https://github.com/technoweenie/restful-authentication/commi.... FYI, still using in production like a charm!
> A great alternative to Auth0, Firebase Auth and AWS Cognito
Can you elaborate a bit on how it's a great alternative, or what is different?
Can you elaborate a bit on how it's a great alternative, or what is different?
1. Neither of these are open source. Also, the only option that can be run on premise
2. We take a modular approach to our architecture. This enables developers to choose only the features SuperTokens they need for their use case. They need not worry about complications associated with other features (eg: SSO and OAuth if you don’t need it) and this in turn makes it easier to implement and manage SuperTokens. This is not true for the others. Regardless of your use case, you likely have to worry about Oauth flows and integrating with a '3rd party' app.
3. Heavy focus on keeping documentation simple and easy to understand. We want to 'just work' for you. We spend a significant amount of our effort on simplifying every step of implementation (this is ongoing and iterative). we've often had complaints from auth0 and cognito users for this.
4. Pricing (compared to Auth0 atleast)
2. We take a modular approach to our architecture. This enables developers to choose only the features SuperTokens they need for their use case. They need not worry about complications associated with other features (eg: SSO and OAuth if you don’t need it) and this in turn makes it easier to implement and manage SuperTokens. This is not true for the others. Regardless of your use case, you likely have to worry about Oauth flows and integrating with a '3rd party' app.
3. Heavy focus on keeping documentation simple and easy to understand. We want to 'just work' for you. We spend a significant amount of our effort on simplifying every step of implementation (this is ongoing and iterative). we've often had complaints from auth0 and cognito users for this.
4. Pricing (compared to Auth0 atleast)
Indeed I’ve chosen each of the above for different projects. I’d really like to know what is different, specifically, about this product.
They have a feature matrix here: https://supertokens.io/pricing
It's at a pretty coarse level of detail, but maybe it will help?
It's at a pretty coarse level of detail, but maybe it will help?
Does anyone knows anything which even remotely comes close to AWS IAM for service to service authn/authz?
Hi. Great work! We are using https://github.com/panva/node-oidc-provider and fairly happy with what it provides. How is it different? better than this popular open-source package?
Thanks for doing this. I've been waiting for this type of solution for a long time.
Let's see how well it works!
Let's see how well it works!
Thank you! Let me if you need any help setting up SuperTokens
Would love to see some code examples on the homepage.
When I did find some code, using "recipe" and "recipeList" in your packages and examples was confusing. At first I thought the example code was a recipe app as the hello world.
What exactly is a "recipe" in the context of supertokens?
When I did find some code, using "recipe" and "recipeList" in your packages and examples was confusing. At first I thought the example code was a recipe app as the hello world.
What exactly is a "recipe" in the context of supertokens?
I understand your confusion. You are right, we need to improve our explanation.
A recipe is essentially an auth experience. So auth with email + password (with forgot password & email verification) is a recipe.
Social login is another recipe. This recipe is independent to the one mentioned above.
There will also be a recipe that has both, social login and email password (like other auth providers).
The idea behind recipe is to allow devs to pick only what they want and not have to think about anything else - making development easier for them.
A recipe is essentially an auth experience. So auth with email + password (with forgot password & email verification) is a recipe.
Social login is another recipe. This recipe is independent to the one mentioned above.
There will also be a recipe that has both, social login and email password (like other auth providers).
The idea behind recipe is to allow devs to pick only what they want and not have to think about anything else - making development easier for them.
I did find amusing that one of the talking point is to not have to trust AWS with your auth, but you offer a SaaS.
(I haven't read details of the SaaS, maybe all data is still hosted outside of your service, but I would doubt it.)
Not a problem, but a bit of a contradiction. OTOH, SaaS does alleviate some pain.
(I haven't read details of the SaaS, maybe all data is still hosted outside of your service, but I would doubt it.)
Not a problem, but a bit of a contradiction. OTOH, SaaS does alleviate some pain.
Yea for those that do not trust a third party, we also offer a self hosted version in which all the data is stored in your own db.
A lot of companies would rather not send their user data to a 3rd party. For those, we offer the option of self hosting. The ones that you do not mind using a 3rd party, we also offer a SaaS version of our product.
And yes, indeed. We will add the option where our SaaS will also write to your own DB as opposed to ours.
And yes, indeed. We will add the option where our SaaS will also write to your own DB as opposed to ours.
Could you provide some details on where you are storing the tokens on the client side to persist the session? The best practice currently seems to be storing the tokens in http only cookies.
I built something not long ago like this for myself. I haven't made it publicly available though.
I built something not long ago like this for myself. I haven't made it publicly available though.
We use httponly cookies too. Yes, we wrote a blog post on cookies vs localstorage too - that you can read here:
https://supertokens.io/blog/cookies-vs-localstorage-for-sess...
This is awesome! And it couldn't have come at a better time. I've been working on my own startup product and shopping around authentication platforms. Auth0 looks great but it's just damn expensive when you start getting more users. Appreciate this!
Simple, JWT, pick one.
Really don't understand the obsession with JWT, especially if you don't need SSO.
Only real advantage of JWT, vs the tried and true random session_id+database approach, is that you don't need the DB.
What useful web application needs auth, and doesn't already have a DB?
Really don't understand the obsession with JWT, especially if you don't need SSO.
Only real advantage of JWT, vs the tried and true random session_id+database approach, is that you don't need the DB.
What useful web application needs auth, and doesn't already have a DB?
This is a debatable topic. We wrote a blog post about this as well: https://supertokens.io/blog/are-you-using-jwts-for-user-sess...
The benchmark in that article comparing JWT to opaque session id's doesn't mention what database setup is used or what JWT signing scheme is used.
Presumably it's just using a HMAC, I think if it used RSA or an asymmetric signing scheme, the performance would look much different.
Presumably it's just using a HMAC, I think if it used RSA or an asymmetric signing scheme, the performance would look much different.
Yes. It was using HMAC. But I would still assume that RSA would be much faster than a db lookup (in a distributed system)?
[deleted]
Perhaps, at least on the JDK[0] RSA can take a few ms, probably a fair bit faster with a native implementation though.
[0] https://www.javamex.com/tutorials/cryptography/rsa_key_lengt...
[0] https://www.javamex.com/tutorials/cryptography/rsa_key_lengt...
JWT has one useful feature indeed: it separates issuing the token from verifying the token. For verifying the token, all you need is the token and some simple JWT library that takes care of verifying the signature. You don't need network access, you don't need a custom service that you need to call into, etc. Especially if you have multiple services, this is great since it is low complexity and easy to understand. Add the header, check the signature, done.
Issuing the token is likewise very simple if you have users and passwords. Check some user/password combination that you store somewhere (bcrypt, obviously) and issue the token. I recently implemented this again for a startup. Took me an afternoon. Works. I also know how to add 2FA/TOTP to the mix (done that as well). Not that hard. All you need is a shared secret between the account and the totp token app.
The part that remains complicated is the signup and account verification process. It's depressing that people continue to use email verification + password signins simply because nobody wants to work together to federate identity. Email is merely the simplest form of federated identity where the check is basically "please prove that you can read the email we just sent you". Never mind that email providers come in all sorts of easily compromised forms and that that does not provide any additional guarantees about the individual. Believe me, I've dealt with bot created gmail, yahoo, and other accounts. Somebody owning a gmail account proves exactly nothing. So it's a weak check and people connecting their entire online life to a single email provider is an obvious security risk. Countless idiots out there with poorly protected gmail accounts and nothing but a stupidly insecure password that they use on every website to protect them. Perpetuating that is almost criminal at this point.
But it's relatively easy to do and everyone has an email address so people continue to do this. Phone operators briefly tried to take over with SMS verification but that got hopelessly complicated because they wanted to earn money per SMS and most of them were more than a bit security challenged thus making this more complicated, less convenient, and less secure than email verification. Even as a second factor some (e.g. MS recently) are recommending to stop doing phone verification.
I'd love to have some simple mechanism that would simply allow me to verify that "the holder of this token was authenticated by X". That's all I need. It doesn't have to be super complicated. Sadly OpenId and later OpenId 2.0 and OpenID Connect descended into design by committee stuff where the committee was populated by people with every incentive to guarantee vendor lock-in to their mutual proprietary solutions. Add your favorite trillion $ companies to the mix that each want to "own" their users for exploitation purposes and "simple" was ruled out as design goal for any of this. Nothing wrong with the original vision but there seems to be a lack of unambiguously standardized, easy to integrate, reliable identity providers (Banks, local government, etc.). The whole field is a mess where everyone does things slightly differently; thus necessitating middle men like Auth0 or AWS Cogito.
So, countless startups keep throwing in the towel in the ring and go "fuck it, email signup + passwords it is yet again". It's stupid, but it's also simple which is why it is so resilient. I know all this and yet I'm already down a path where I will soon have to implement this yet again. DYI security is not something we should have to do in 2021. But it seems it will remain common for some time.
Issuing the token is likewise very simple if you have users and passwords. Check some user/password combination that you store somewhere (bcrypt, obviously) and issue the token. I recently implemented this again for a startup. Took me an afternoon. Works. I also know how to add 2FA/TOTP to the mix (done that as well). Not that hard. All you need is a shared secret between the account and the totp token app.
The part that remains complicated is the signup and account verification process. It's depressing that people continue to use email verification + password signins simply because nobody wants to work together to federate identity. Email is merely the simplest form of federated identity where the check is basically "please prove that you can read the email we just sent you". Never mind that email providers come in all sorts of easily compromised forms and that that does not provide any additional guarantees about the individual. Believe me, I've dealt with bot created gmail, yahoo, and other accounts. Somebody owning a gmail account proves exactly nothing. So it's a weak check and people connecting their entire online life to a single email provider is an obvious security risk. Countless idiots out there with poorly protected gmail accounts and nothing but a stupidly insecure password that they use on every website to protect them. Perpetuating that is almost criminal at this point.
But it's relatively easy to do and everyone has an email address so people continue to do this. Phone operators briefly tried to take over with SMS verification but that got hopelessly complicated because they wanted to earn money per SMS and most of them were more than a bit security challenged thus making this more complicated, less convenient, and less secure than email verification. Even as a second factor some (e.g. MS recently) are recommending to stop doing phone verification.
I'd love to have some simple mechanism that would simply allow me to verify that "the holder of this token was authenticated by X". That's all I need. It doesn't have to be super complicated. Sadly OpenId and later OpenId 2.0 and OpenID Connect descended into design by committee stuff where the committee was populated by people with every incentive to guarantee vendor lock-in to their mutual proprietary solutions. Add your favorite trillion $ companies to the mix that each want to "own" their users for exploitation purposes and "simple" was ruled out as design goal for any of this. Nothing wrong with the original vision but there seems to be a lack of unambiguously standardized, easy to integrate, reliable identity providers (Banks, local government, etc.). The whole field is a mess where everyone does things slightly differently; thus necessitating middle men like Auth0 or AWS Cogito.
So, countless startups keep throwing in the towel in the ring and go "fuck it, email signup + passwords it is yet again". It's stupid, but it's also simple which is why it is so resilient. I know all this and yet I'm already down a path where I will soon have to implement this yet again. DYI security is not something we should have to do in 2021. But it seems it will remain common for some time.
“We couldn’t afford to pay It took too long to understand the documentation of alternate service providers”
These don’t seem like good reasons and would be enough to make me not want to use this until it already has a lot more real-world usage from others first.
These don’t seem like good reasons and would be enough to make me not want to use this until it already has a lot more real-world usage from others first.
Thank you for your candid feedback. Those reasons were also echoed in our user research as we were dedicating ourselves to the project.
Could you please share why you think those arent good enough reasons? Ofcourse, social proof is important regardless. SuperTokens is being used in the real world, in production. Would you like to see more people using it or some recognizable entreprise brand names?
Could you please share why you think those arent good enough reasons? Ofcourse, social proof is important regardless. SuperTokens is being used in the real world, in production. Would you like to see more people using it or some recognizable entreprise brand names?
It's not the technique that makes me wary - it's that the way it reads is that you've built this because you found the documentation for existing solutions to be too complex which is a massive red flag with regards to anything security related.
Essentially it sounds like "doing security is hard so we did something simpler and ignored the complicated parts we couldn't understand".
As you've explained it above that's clearly not what you meant at all so maybe edit the website to call out a bit more clearly what your reasons are for building this and what other people's complaints are about existing systems? (Maybe in one of those side-by-side feature matrices showing the benefits of your implementation?)
Will definitely check this out when I have some time though!
Essentially it sounds like "doing security is hard so we did something simpler and ignored the complicated parts we couldn't understand".
As you've explained it above that's clearly not what you meant at all so maybe edit the website to call out a bit more clearly what your reasons are for building this and what other people's complaints are about existing systems? (Maybe in one of those side-by-side feature matrices showing the benefits of your implementation?)
Will definitely check this out when I have some time though!
Actually we offer the most secure way of managing session tokens. We were the first provider to implement token theft detection using rotating refresh tokens (and most still dont). Auth0 even uses one of our libraries for solving for edge cases. I dont think that good security = complex documentation. Its about the way you abstract away the complexity.
Will factor your feedback when we design the website and think about communication.
Please do let me know when you've had a chance to check it out. Would be happy to hear your feedback
Will factor your feedback when we design the website and think about communication.
Please do let me know when you've had a chance to check it out. Would be happy to hear your feedback
It makes sense to me. Here is my understanding of what they are trying to say:
"The existing services were either too expensive or too complex, we thought we could do better"
That is a typical iterative product design that many companies choose.
"The existing services were either too expensive or too complex, we thought we could do better"
That is a typical iterative product design that many companies choose.
This is amazing! Wish you a lot of success. Will there be a way to submit feature requests, upvoting and you working on the most requested?
Would be great if you would add user management, including profile photos and custom fields in the future. And SMS login.
Would be great if you would add user management, including profile photos and custom fields in the future. And SMS login.
Thank you!
We do keep track of all feedback and requests on a private Github repo and use that to prioritize. However, I agree - maybe we can have a public page where users can submit and vote for their preferences.
We're excited about user management too! We already have custom fields that you can add to the SuperTokens sign up / sign in form. We'll add passwordless soon after social login / email verification
We do keep track of all feedback and requests on a private Github repo and use that to prioritize. However, I agree - maybe we can have a public page where users can submit and vote for their preferences.
We're excited about user management too! We already have custom fields that you can add to the SuperTokens sign up / sign in form. We'll add passwordless soon after social login / email verification
This speaks to me. I will patiently wait for SSO capability. With that being said, if anyone has built scalable SSO flows specifically Azure AD, and want to help us implement it - please get in touch.
Thank you! We appreciate it and hope to make that wait as short as possible
I will be happy to speak. My team specialise in identity and SSO implementations. In fact we also have our own identity product Axioms (https://axioms.io/).
We can help. Check it out here. https://datawiza.com. Also we are a Microsoft partner.
This is a good idea. But I think a lot of your potential customers will struggle until you get OAuth2/SAML options, so they use you can offer premium auth options for their enterprise customers.
For anyone else wondering: the frontend depends on NodeJS and the backend is Java.
Ooof.
Ooof.
What's wrong
I came here to question exactly that.
> Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon
That's a very very odd combination.
> Note: Login is currently available only for Nodejs. Other tech stacks will be supported soon
That's a very very odd combination.
So the core is written in Java. The core is a http microservice that contains the main auth logic + interacts with the database.
The backend API queries the core for sign in / sign up / sessions etc... This can be in any framework, and we decided to choose NodeJS first. Here, the user does not have to interact with Java at all.. just simply use our NodeJS SDK that internally calls the core's APIs
The backend API queries the core for sign in / sign up / sessions etc... This can be in any framework, and we decided to choose NodeJS first. Here, the user does not have to interact with Java at all.. just simply use our NodeJS SDK that internally calls the core's APIs
We have SDKs for other backend frameworks as well (like golang, laravel...). But those only have a session feature, and not login. Hope this provides some clarification.
I was mostly confused that you would write something in Java that doesn't target Java.
I'm writing stuff in Java (and Kotlin and Clojure) and, even though it looks cool, won't look too closely unless it supports Java.
I'm writing stuff in Java (and Kotlin and Clojure) and, even though it looks cool, won't look too closely unless it supports Java.
Yup. This. Give us an embedded library that will work with my Java app. JAX RS or or at least callable from within my JAX RS resource. Spring would be nice, too.
Do you have a ETA for flask login support? I literally just rolled my own but I'll want to switch it over at some point.
We expect to have Flask login ready sometime early next year. If you could drop me an email on advait at supertokens.io - I'll let you know when its released!
The SuperTokens microservice is in Java. The backend can be in anything (like nodejs) - for which we have an SDK that developers interact with.
Can you confirm that you don’t recommend storing session tokens in localStorage / anything accessible by client-side JS? (It’s a commonly recommended bad practice these days)
Yes, we do not recommend storing tokens in localstorage. This is also recommended by other security bodies such as OWASP and NIST. We've written a blog post on this topic as well, that you can read here:
https://supertokens.io/blog/cookies-vs-localstorage-for-sess...
https://supertokens.io/blog/cookies-vs-localstorage-for-sess...
Great! Pleased to see this :)
I really wish there was a sane, simple common standard that all of these identity providers could implement. OAuth is (IMHO) far too complex. Anyone know of any other proposals?
I am psyched about the prospects. Cannot wait to be a beta user.
We're so glad to hear! Are you currently working on a project that requires auth? We'd love to have you on :)
Thank you for working on such a horrible problem for developers. Looks amazing tbh. Will definitely try this out on a future project.
Edit: open source part = huge. Great work
Edit: open source part = huge. Great work
Thank you for your kind words - its really encouraging! Please do let us know when you are trying it out, we'd be happy to help and hear your feedback. You can join our discord (https://supertokens.io/discord) or email me at advait at supertokens [dot] io
I looked around on the site and couldn't find any explanation about how it works, a diagram of the auth flow, or even a gif showing how the flow works.
One important point is that we do not follow the OAuth 2.0 protocol since for simple email password login without SSO, we do not need to provide OAuth.
So the login part, is a simple API call with the email / password. On success, a session is created, and the flow for that is provided here (in a diagram): https://supertokens.io/docs/emailpassword/common-customizati...
So the login part, is a simple API call with the email / password. On success, a session is created, and the flow for that is provided here (in a diagram): https://supertokens.io/docs/emailpassword/common-customizati...
My specific need is passwordless login (via email currently) to issue private keys for multi device end to end encryption. If you can do that, I'm in!
We had actually implemented email passwordless for our own website earlier. We havent launched it yet but are hoping to do so. i'd love to update you when we launch it. Please share your email ID or drop me an email at advait at supertokens.io and I'd be happy to let you know when we have it.
but with multi device E2E key pairs? That for me is the real challenge.
[deleted]
I guess not, since it's for nodejs only. I would use it if it had a frontend component and instructions for implementing the backend component.
We do have a frontend component as well as instructions for implementing the backend. Currently we support login for nodejs and session management is supported for several frameworks. We will be adding login support in the near future
It looks like step 1 of integrating supertokens is writing a driver, and if I would like to do this the docs invite me to chat about it on Discord.
How does this compare to Keycloak? https://www.keycloak.org/
Keycloak is a worthy alternative, no doubt. There are a few reasons we built SuperTokens - despite knowing about Keycloak:
In general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one (but this is not true for everyone).
We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity.
We provide far more flexibility and options on the frontend as well
KeyCloak is a small part of the Redhat (and even less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).
Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.
We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.
If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
In general, we've had feedback from Keycloak users that they've had a poor experience deploying and managing Keycloak and would switch to a good alternative, if there was one (but this is not true for everyone).
We've taken a modular approach which is different from most. This enables you to only pick the features you want for your use case and not worry about unnecessarily complexity.
We provide far more flexibility and options on the frontend as well
KeyCloak is a small part of the Redhat (and even less significant for IBM, the owner of Redhat). For us, our team and company is 100% dedicated to building auth. Its do or die for us. While this may not sound tangible, we'll constantly be innovating (and hopefully out executing keycloak).
Keycloak does not offer a hosted version of the offering. In our opinion, a hosted open source product is still quite distinct from a proprietary SaaS product.
We provide the most robust solution for managing session tokens. We mitigate against all types of attacks and detect token theft using rotating refresh tokens. One of our libraries to solve for edge cases (browser tabs lock) is actually used by Auth0 as well and has 250K weekly downloads on npm.
If you do get the opportunity and decide to try out supertokens, we'd love to hear about how your experience compares between the two.
This looks cool, I’d love to add it as a provider in https://useAuth.dev
Can’t wait to dig in
Can’t wait to dig in
I wrote this in 2002 in PHP and the world didn't care, it thought PHP nuke was the thing. I got two good jobs out of it so it was good.
Is this similar?
https://github.com/Bearer/Pizzly
https://github.com/Bearer/Pizzly
[deleted]
How does this differ from something like Gluu?
Anybody using https://magic.link/ ?
On a technical level how does this compare to Mozilla Persona?
Still sad that Persona died before it could gain some traction.
Still sad that Persona died before it could gain some traction.
Is it there any support for a premade UI like firebase does? that's a great time saver for prototypes
Yes, SuperTokens comes with pre made UI. You can choose from one of the three themes we have available and can easily customize the colours / CSS for either of those themes. We also make it possible to easily add your own theme if you like.
The docs are here: https://supertokens.io/docs/emailpassword/common-customizati...
The docs are here: https://supertokens.io/docs/emailpassword/common-customizati...
[deleted]
I really love what you are doing guys. Self-hosted option with SaaS model as an alternative - sweet, perfect pricing balance.
I don't know about others but I am really tired of settings up auth over and over again for over 8 years already. Don't give me firebase it sucks so hard I can't even open my eyes when auth needs more control or extension. Im going to give you a shot in my next project
I don't know about others but I am really tired of settings up auth over and over again for over 8 years already. Don't give me firebase it sucks so hard I can't even open my eyes when auth needs more control or extension. Im going to give you a shot in my next project
Thank you! Really appreciate your kind words :) Have a great day
Out of interest, what's your plan for making a living with an open source product?
We will monetize features that are required by large enterprises. Features needed by developers / startups will largely be free. We have a pricing philosophy section on our pricing page that goes into more details about this :)
How would you compare this with something like openam or spring security?
I don't get the Stripe comparison here. Otherwise, looks great.
Please consider adding support for Vue & Nuxt ASAP. Thanks.
I would love to try it. Do you have a plan for a .NET Core SDK?
How would this work for Windows and MacOS desktop applications?
feedback after 30s of looking into this - i'm not understanding what this is without email verification and social login
For now, it's just email, password login, with forgot password flow and secure sessions. Email verification is next followed by social login :)
Thanks for your feedback
Thanks for your feedback
Is SAML Authentication on the roadmap?
We plan on supporting it, but don't have a definite date for it as of yet.
Does it have spring-boot integration?
Supertokens seem great for any startup and many use cases. But a critical part for many enterprise organisations is compliance and strong security. Does it ensure compliance around GDPR, HIPAA, PCI-DIS etc?
Will consider after go library introduced.
Why did we build this? To be able to control our user data and have it stored in our own database. Have certain customisations that other identity providers do not offer We couldn’t afford to pay It took too long to understand the documentation of alternate service providers
How are we any easier? We think that Auth0, Firebase etc are great services but auth is complex. There are many different use cases for different types of apps. Since services have to cater to each of these, they tend to become complex in their implementation (due to no fault of their own).
SuperTokens takes a modular approach - making it possible to pick only the features you need for your use case. This means you need not worry about complications associated with other features (eg: SSO and OAuth if you don’t need it) and this in turn makes it easier to implement and manage SuperTokens.
We are still early in the journey and working hard on building more functionality.
Please see our website: https://supertokens.io/ Our GitHub: https://github.com/supertokens/supertokens-core
Do let us know what you think - specifically whether you would consider SuperTokens for your app. Why or why not? What can we change or offer?
PS: We did a "Launch HN" post earlier when our product was only for securely managing session tokens (https://news.ycombinator.com/item?id=24306572). We realized we need to build more of the auth stack (signup / signin, social login etc) and hence we're excited to announce that we've built basic login functionality.