[HN Gopher] Sick of spending time on Auth, we built an open sour...
___________________________________________________________________
Sick of spending time on Auth, we built an open source 'Stripe for
Auth'
We (my cofounder and I) have built several startups previously and
spent an unnecessary amount of effort on auth. This led us to build
an open source alternative to Auth0 and AWS Cognito, that's called
SuperTokens. We've spoken to 100s of developers and startups to
understand the pain points with current services and we hope you
find this useful! 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.
Author : advaitruia
Score : 277 points
Date : 2020-12-17 17:48 UTC (5 hours ago)
| harrisonjackson wrote:
| 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?
| rishabhpoddar wrote:
| 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.
| tziki wrote:
| Out of interest, what's your plan for making a living with an
| open source product?
| advaitruia wrote:
| 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 :)
| defnotanai wrote:
| 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?
| advaitruia wrote:
| 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?
| defnotanai wrote:
| I think you confused the threads :)
| advaitruia wrote:
| 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?
| rossmohax wrote:
| Does anyone knows anything which even remotely comes close to AWS
| IAM for service to service authn/authz?
| 0xbadcafebee wrote:
| 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)
| advaitruia wrote:
| 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.
| tomc1985 wrote:
| Am I the only one weirded out by this page using the word "auth"
| exclusively? Like is this some kind of slang now?
| pupdogg wrote:
| 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!
| matt_s wrote:
| 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.
| [deleted]
| advaitruia wrote:
| 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.
| mfbx9da4 wrote:
| 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!
| advaitruia wrote:
| 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.
| ignoramous wrote:
| 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/
| advaitruia wrote:
| 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.
| corytheboyd wrote:
| 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 :)
| advaitruia wrote:
| 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!
| corytheboyd wrote:
| 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 :)
| advaitruia wrote:
| Yes, thats exactly it - from our experience with talking to
| devs and startups. Once the project starts scaling, things
| change
| anonytrary wrote:
| Yeah I don't mind setting up auth. It takes like a week at most
| for your MVP.
| leesalminen wrote:
| 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.
| frenchman99 wrote:
| 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.
| nullsense wrote:
| Agreed. Done right it's a huge time suck.
| jrockway wrote:
| 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.)
| highmastdon wrote:
| 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!
| jrockway wrote:
| 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/ex
| tension...
|
| (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.)
| karakot wrote:
| I never did it, what is a good guide to start? Thanks!
| tynorf wrote:
| OWASP is a good resource for web security related topics.
| i.e. https://cheatsheetseries.owasp.org/cheatsheets/Authentic
| atio...
| corytheboyd wrote:
| 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.
| chaostheory wrote:
| 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.
| corytheboyd wrote:
| Nothing wrong with that, that's the right mindset for getting
| things done
| kkirsche wrote:
| 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?
| rishabhpoddar wrote:
| Yea! Integrations with OSO makes sense! We do have plans to
| support language specific client libraries.
| silasdavis wrote:
| 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
| AlphaSite wrote:
| How does this compare to something like Dex or Ory?
| InvOfSmallC wrote:
| Will consider after go library introduced.
| arcturus17 wrote:
| 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.
| simonbarker87 wrote:
| Which SDK/package did you use for Firebase and React? There
| seem to be half a dozen and ReactFire the most dated?
| arcturus17 wrote:
| 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.
| simonbarker87 wrote:
| Thanks
| ehutch79 wrote:
| 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.
| arcturus17 wrote:
| 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)
| samirsd wrote:
| 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.
| arcturus17 wrote:
| 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.
| savrajsingh wrote:
| considering flask-login for a new project, should I consider
| firebase instead? I do like most parts of GCP
| advaitruia wrote:
| Would love to know what is preventing you from considering
| SuperTokens
| advaitruia wrote:
| 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!
| arcturus17 wrote:
| 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!
| mooreds wrote:
| > 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.
| arcturus17 wrote:
| 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?
| OJFord wrote:
| Sick of spending your time on auth, you decided to spend all your
| time on it?
| advaitruia wrote:
| 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
| Zealotux wrote:
| If a thing annoys you it'll probably annoy a lot of people that
| are probably willing to pay to solve the problem.
| advaitruia wrote:
| Exactly
| quickthrower2 wrote:
| 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.
| chaostheory wrote:
| It's a pain point. It's always a good place to plant your flag.
| robertlagrant wrote:
| 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.
| pedalpete wrote:
| 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.
| munchbunny wrote:
| 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?
| d33lio wrote:
| 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).
| rishabhpoddar wrote:
| 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.
| nicoburns wrote:
| > 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.
| rishabhpoddar wrote:
| Oh! Thanks for the heads up! I have created an issue about
| this on our github, referencing this comment.
| treve wrote:
| 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
| lukerohde wrote:
| Is SAML Authentication on the roadmap?
| rishabhpoddar wrote:
| We plan on supporting it, but don't have a definite date for it
| as of yet.
| stevemadere wrote:
| I am psyched about the prospects. Cannot wait to be a beta user.
| advaitruia wrote:
| We're so glad to hear! Are you currently working on a project
| that requires auth? We'd love to have you on :)
| Traubenfuchs wrote:
| Does it have spring-boot integration?
| Scotrix wrote:
| 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.
| abraae wrote:
| 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.
| antoineMoPa wrote:
| 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.
| [deleted]
| lmcnearney wrote:
| I would be careful depending on Keycloak given what happened
| with CentOS recently:
|
| - https://www.gluu.org/blog/keycloak-is-the-next-centos/
| n_kr wrote:
| 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.
| agilob wrote:
| > 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.
| linsomniac wrote:
| 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!
| advaitruia wrote:
| 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.
| korijn wrote:
| How about keycloak-gatekeeper? Do you offer something
| similar?
| rboyd wrote:
| Is SuperTokens multitenant capable? My understanding is that
| keycloak suffers in a multitenant enviroment with a
| sufficiently high number of tenants.
| carlsverre wrote:
| I had the same question - apparently the answer is yes:
| https://supertokens.io/docs/emailpassword/common-
| customizati...
| jsilence wrote:
| On a technical level how does this compare to Mozilla Persona?
|
| Still sad that Persona died before it could gain some traction.
| cleansy wrote:
| 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.
| rishabhpoddar wrote:
| Thanks for the heads up!! We will fix this ASAP.
| pbronez wrote:
| 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.
| advaitruia wrote:
| 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!
| arcturus17 wrote:
| 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.
| pierrebai wrote:
| 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.
| advaitruia wrote:
| 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.
| rishabhpoddar wrote:
| 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.
| inssein wrote:
| > 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?
| ryanmarsh wrote:
| Indeed I've chosen each of the above for different projects.
| I'd really like to know what is different, specifically, about
| this product.
| Uptrenda wrote:
| 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
| advaitruia wrote:
| 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
| vmception wrote:
| 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?
| advaitruia wrote:
| 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
| timwis wrote:
| 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)
| advaitruia wrote:
| 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...
| timwis wrote:
| Great! Pleased to see this :)
| ucarion wrote:
| Is it fair to categorize the pitch here as "a simpler AWS
| Cognito"?
| rishabhpoddar wrote:
| Simpler and open source AWS Cognito.
| snissn wrote:
| feedback after 30s of looking into this - i'm not understanding
| what this is without email verification and social login
| rishabhpoddar wrote:
| 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
| tarasmatsyk wrote:
| 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
| rishabhpoddar wrote:
| Thank you! Really appreciate your kind words :) Have a great
| day
| funnyenough wrote:
| 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?
| romtx wrote:
| 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.
| advaitruia wrote:
| 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).
| madelyn wrote:
| 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!! :)
| advaitruia wrote:
| 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
| owlbynight wrote:
| 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.
| rishabhpoddar wrote:
| Thanks for the encouragement :) We will be happy to help when
| you get started.
| mbullington wrote:
| 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.
| advaitruia wrote:
| 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
| fakedang wrote:
| > 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?
| desireco42 wrote:
| 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.
| advaitruia wrote:
| 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
| [deleted]
| mooreds wrote:
| 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.
| rishabhpoddar wrote:
| 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.
| codingdave wrote:
| 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.
| rubicon33 wrote:
| Firebase Auth. One and done.
| leesalminen wrote:
| Can confirm. Just built out a little react MVP using
| firebase. Auth took mere minutes.
| jlvdh wrote:
| 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
| rishabhpoddar wrote:
| 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).
| oakst wrote:
| For what it's worth I think email verification functionality
| would make me more keen to use a service like this!
| advaitruia wrote:
| 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
| MH15 wrote:
| If email (or another mode of ) verification was added I'd be
| entirely on board for my next project (still in planning
| stage)
| advaitruia wrote:
| 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 :)
| leetrout wrote:
| 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!
| rishabhpoddar wrote:
| 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.
| mike_d wrote:
| For anyone else wondering: the frontend depends on NodeJS and the
| backend is Java.
|
| Ooof.
| rishabhpoddar wrote:
| The SuperTokens microservice is in Java. The backend can be in
| anything (like nodejs) - for which we have an SDK that
| developers interact with.
| afandian wrote:
| 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.
| rishabhpoddar wrote:
| 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.
| afandian wrote:
| 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.
| ccleve wrote:
| 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.
| rishabhpoddar wrote:
| 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
| notretarded wrote:
| What's wrong
| markandrewj wrote:
| 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.
| advaitruia wrote:
| 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...
| Swizec wrote:
| This looks cool, I'd love to add it as a provider in
| https://useAuth.dev
|
| Can't wait to dig in
| lwb wrote:
| 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.
| NicoJuicy wrote:
| Any reason why you didn't use identityserver to host it
| yourselve?
| advaitruia wrote:
| 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.
| lwb wrote:
| That answers it, thanks!
| keithnz wrote:
| I'd be +1 on C#, and +1 for SqlServer
| abhishektwr wrote:
| 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.
| advaitruia wrote:
| Thank you! Best of luck :)
| pgt wrote:
| 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.
| j_m_b wrote:
| > 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.
| ridaj wrote:
| Authentication is not a solved problem. Every ecommerce website
| out there rolls their own, usually with obvious flaws. Some
| major banks too.
| p932 wrote:
| 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/
| rkeene2 wrote:
| 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.
| bg0 wrote:
| 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.
| advaitruia wrote:
| Thank you! We appreciate it and hope to make that wait as short
| as possible
| abhishektwr wrote:
| 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/).
| thaumasiotes wrote:
| 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". :/
| rishabhpoddar wrote:
| Hahahaha. Fair enough. And it get's even worse when talking
| about sessions and tokens...
| lmeyerov wrote:
| 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!
| PaulHoule wrote:
| 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.
| foreigner wrote:
| 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.
| advaitruia wrote:
| 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?
| ForHackernews wrote:
| How does this compare to Keycloak? https://www.keycloak.org/
| advaitruia wrote:
| 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.
| agentdrtran wrote:
| How does this differ from something like Gluu?
| headmelted wrote:
| "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.
| advaitruia wrote:
| 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?
| xupybd wrote:
| 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.
| tacitusarc wrote:
| 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?
| rishabhpoddar wrote:
| 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..)
| sidhuko wrote:
| > 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.
| advaitruia wrote:
| 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
| winkelwagen wrote:
| 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!
| redkoala wrote:
| +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.
| rishabhpoddar wrote:
| 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.
___________________________________________________________________
(page generated 2020-12-17 23:00 UTC)