It seems interesting but does the user have to check email any time he/she decides to log in to my service?
If so i don't consider it interesting.
I would consider very interesting something similar to firebase authentication without having to include all the google privacy killer stuffs and for free.
(Edit: i didn't read the text where you explain how you make money)
Thanks for the feedback! Currently passwordless email confirmation is the only supported login flow, but I’m thinking about building alternatives like Twitter OAuth, or a password based flow.
Does the pricing model make this less appealing to you? Open to adjusting it!
Well since i'm interested only on the auth part, it would be ok for me and if i had to charge i would implement Stripe my self in the project so i'm not sure you will be able to raise a lot of money
I like the idea but what benefits do you provide over using SSO with Google and setting up stripe myself? I'm not sure ease of use would bring me to use you over what is currently available
If I had some smaller website that I charge nothing or barely anything on, I might. If I had a bigger SaaS product, probably not. I wouldn't say your pricing is necessarily unfair, but paying 5% for what is probably a very small part of the application, I couldn't stomach.
I have to say I'm personally pretty allergic to fees. Even Stripe's fees are above what I really feel comfortable with, but I'd probably pay those to deal with payments less. Anything above 1% and I'd probably be out, to be honest.
As an alternative to a fixed percent, I'd feel a lot better about a model where the fee gets progressively less with a larger amount of users. This may or may not be a personal thing.
FWIW: I think the user you are replying to is honest but an unusual case.
5% on payments might be OK until things starts to take off.
Source: I've helped launch a successful business with Shopify and Paypal 10 or so years ago. Maybe could have saved a lot in fees but that solution was so nuch easier than the rest that it was easily worth it.
Edit: the webshop and payment solution was later changed to something less expensive.
While it's interesting that you're thinking outside the box on pricing models, I would personally never signup for a login service on a revenue sharing basis - I'd much prefer a monthly fee (the standard SaaS model). The percentage also seems way to high in comparison to the value-add - Stripe, who actually process the payment, are taking less than you.
Having said that, I don't think I (or most of HN) would be the target market for this kind of login service.
But I wonder if you can find some kind of niche. Something for individuals and micro businesses that have no tech chops and just want an easy way to sell stuff. For that though, you'd need to go further than login, perhaps turning it into a WordPress plugin (or for another platform), and doing something to provide sales through Stripe, so the user doesn't have to build that themselves.
I think an issue to monetize this is that if you build a web app, you are going to have a way to send emails, and a "users" table.
Implementing email login on top of that is probably as easy as integrating with an external service, without the risk and the concerns about leaking user emails.
A percentage fee, or even a per-user fee, would push me to do it by myself. A bad login mechanism takes a couple of hours to be integrated. A well done one, could take maybe a week (very well done, 1 dev, extreme case), but a percentage fee for any kind of decent revenue would reach that same cost within a year.
I see this working maybe for a single dev shop, but then you might prefer saving every cents you want.
Paying a fixed fee might work, but if you start charging per single user, it's problematic. I can see some value if it's per bundle of users (e. G. Every 10 users the pricing increases)
Why would anyone use this? Just write your own login, it's not hard, and you don't have the dependency on a 3rd party site that can go down at any point in time.
I agree that writing your own login routines is not hard, except I wouldn’t want anyone to have the impression that it’s trivial.
It’s not trivial. It requires some knowledge to do it well. Off the top of my head—choice of unique identifier, password complexity rules, hashing best practices, registration flows, recovery flows, abuse detection, markup hinting for password managers... I could go on.
Wouldn’t it be „wrong“ to teach my users to trust login emails coming from a foreign domain? Also, how do you plan to keep your emails out of spam folders and blacklists? From your website it wasn’t clear to me how I would check the login code for validity.
Original intent notwithstanding, defaulting communication to a junk box is absolutely the correct stance given the current signal to noise ratio in email.
First thing I noticed, hovering the big "Get started" button did not change my mouse cursor to a link-pointer. Just a small suggestion :).
Edit: Also, after clicking on "Get Started", the first field (email) should be in focus so the user can start typing, without having to move their mouse and click it first.
Edit 2: I love the simplicity of this tool. The interface is pretty good (but not yet great). How can I contact you?
- for trivial projects, I don’t want them to stop working one day
- for more serious services, moving login to a third party is a huge risk. The upside isn’t worth the risk. Even if it did your pricing is way too expensive, but that could be fixed.
No, not me personally, however if someone lacked the skill to build a login system and lacked the risk aversion to outsourcing it (which I’m guessing is not uncommon because that risk aversion comes with experience) then perhaps there is a market at the right price.
Your fee example seems either plain wrong or dishonest. If you use Stripe to handle payments, the fee of using your service must be higher than using Stripe directly. But you claim that Stripe would take 35c, but you only 25c.
If so, that‘s what I would call dishonest pricing. I expect you to tell me your fee, and that should include all your internal cost of providing the service. Sounds like an architect selling a house for 10k. But wait, footnote says „don‘t forget the contractors will take an additional 100k“.
I’ll try to make this clearer, thanks for the feedback! You’d pay both, the Loginland fee on top of Stripe’s rate. (This is a pretty common pricing model for platforms – BuyMeACoffee has a similar 5% rate on top of Stripe). Open to suggestions! :)
I am afraid, I would not use it. As others pointed it out, login is such a small part of a system that it's not worth employing a 3rd party service to get it working.
Also, using this service requires trust. I personally don't use nor implement FB, Google, etc logins either as I don't trust them.
If my app is small, I'll roll my own or use the free tier from Auth0 or Okta.
If my app gets big, I'll roll my own or pay for Auth0 or Okta.
Like a lot of SAAS ideas, a login service is: too critical to trust with an unknown, already a mature SAAS offering elsewhere, and easy enough to implement yourself if you don't want to pay for it.
I'd rather set up login functionality on my own server. If you use a third party service, their downtime becomes your downtime. Worse, you're injecting another company into your relationship with your users. If that were necessary, I'd choose one the customer was already familiar with, like Google, Facebook or Twitter.
Setting up login isn't very difficult and libraries exist for most webdev languages to make it even easier. It's definitely not worth 5% of my revenue.
Login management should be built into the browsers instead. Imagine a UI where you go to log in and instead of a text/email field for login and a password field you get a drop down with a list of your personas that you’ve created with the option of adding a new one. Under the hood it would use a public/private key pair to authenticate you with the site.
Browsers could implement a service that backs up your personas and syncs them across your devices. Ideally the syncing should be cross browser too and allow me to use my own servers for this if I choose.
That sounds very much like the goals of Mozilla's Persona service. While it required a separate service and some JavaScript, the idea was that it could be supported natively by browsers in the long run.
Unfortunately, it was shut down in 2016 due to lack of interest. (Coincidentally, I just spent this past week hacking on its source code.)
Yes that’s pretty much what I was thinking of. It’s unfortunate Mozilla couldn’t keep it going. I wonder if a browser extension could make this work as a way to pave the way forward. Or if like LastPass could add such functionality.
I don't like this idea, it makes using a public/cafe computer impossible. It would also force me to have a work browser and personal browser on all my devices. I am also not a fan of google chrome trying to log me into every site with my google profile.
It isn't necessarily any worse for public/cafe computers. Just like any login system, the UI should have the ability to remember you or not.
With the browser acting as your user agent, it can manage multiple contexts (work, personal) and let you choose which is sent to each site, without the need for separate browsers for each.
As an added tangent, consider that browsers are one of the few places where we can do things like "temporarily log me out of everything" (Incognito Mode / Private Browsing). They have some level of sophistication in session management already.
> Login management should be built into the browsers instead.
I would go even further than this, and say that a cryptocurrency might be among the best ways to build a universal login system. Imagine an Ethereum-like coin where the wallet is the username, and you spend the coins while authenticating, gaining privileges, and the blockchain stores your public info like a username and avatar that you can bring to any website.
I don’t want every login to become a part of the public ledger. Do you? Also, crypto currencies are a good solution for one thing only: electronic currencies. Outside of that they are a poorer solution compared to what’s available now. Every time.
> crypto currencies are a good solution for one thing only: electronic currencies.
What is a better solution than building a tamper proof workflow in the blockchain? Examples include:
1. I sign a contract and the notary signs and uploads a copy to the blockchain to validate the contract contents, that it was signed and by whom, and when.
2. An auditor validates a piece of evidence a client provides that proves its in compliance with a particular control in some regulatory framework. The auditor uploads a SHA256 hash of the evidence in a transaction memo to the blockchain to validate against later in peer review, a lawsuit, etc.
Edit: My examples here refer to a valid use case of a blockchain and not cryptocurrencies which is what you mention, but based on context of this discussion it looks like we all actually mean blockchain and not necessarily cryptocurrency.
Those are useful examples of a blockchain. But when I log into GMail I (a) do not want this fact to be a part of a public ledger and (b) I don’t need this to be trustless. The latter is an important point: I already trust GMail with a ton of my data including the ability to reset my credentials. There is little value gained and a lot of simplicity lost in adding a blockchain to the mix.
Blockchains have several uses but to date they are narrow. Everywhere outside of their core use cases (essentially contracts or keeping track of tokens of value) they are a hindrance. Blockchains are also hugely inefficient by design (if they were they’d be easy to crack or to perform a 51% attack on), so when you are communicating with a single third party which you trust to provide a service to you, you absolutely do not need a blockchain. We have seen time and time again people trying to throw this solution at all the problems from DNS to buying groceries and yet the only solutions still worth talking about remain cryptocurrencies. Turns out well defined client/server APIs and databases actually do work about as well as anything else.
In the spirit of discussion, what could you do if you involve a blockchain in logging into GMail that you absolutely cannot do without it? If the answer is nothing, then there is zero reason to go down that path.
I agree with your points and overall sentiment, I'm simply rebutting the initial statement in your parent comment,
> crypto currencies are a good solution for one thing only: electronic currencies.
You contradict yourself by stating above you believe there's only one valid use case for blockchain, but in your most recent comment you obviously admit there are several valid use cases (though admittedly a limited number). Maybe your initial comment was meant for emphasis and not literally that you believe there is only one use case, but be careful using quantifiable verbiage or hard numbers to portray emphasis without explicitly stating that's what you're doing, your credibility gets called into question when doing so.
I definitely don't think it's /useless/, but I wouldn't use it. Someone out there wants a dead simple login solution that they can get running with a handful of lines of code.
That being said, if this was /self hostable/, I'd see myself using it on a few projects.
(You know, you can get proper italics. Wrap it in asterisks. Some discover this by accident when it mangles asterisks they meant as literal asterisks.)
While there often are built in modules for lots of platforms, it often becomes not so easy out of the box when a platform scales. Adding login to RoR is easy, but what if there suddenly is a wordpress site serving the articles, some java backend services handling other aspects etc. Or just generally lots of services that are separate. Then one suddenly needs a central authority not built in to any one service.
Then I've seen lots of people offload that to Auth0 or other managed services.
That would be an ideal scenario for a SSO system. There are open source solutions like Keycloak, IdentityServer etc. While they are nice thanks to the functionality they offer, I recently tried Keycloak and found it extremely annoying to maintain thanks to the not great documentation.
Managed services like Auth0 are a great alternative, although Auth0 is one of the more expensive ones.
For small apps I found Firebase Auth to be great, for larger projects things like Amazon Cognito or Azure AD B2C are probably the better choice (although Azure AD B2C still doesn't support custom domains). They are worth a try imho, since Amazon as well as Microsoft offer a generous free teir (50k MAUs for free)
As an Auth0 user, I agree it’s not hard to setup user logins for most frameworks. The reason I’m using Auth0 boils down to business reasons not technical ones.
- If I cant make enough money per user to even pay for Auth0, why am I working on this?
- Auth0 provides more than login, its got logic related to token re-validation, signup pipelines, social platform integration, etc... sure, I could build each of these as I needed them, in fact I did previously build them for myself. However by using Auth0 I know in advance that all this kind of functionality will be available when/if I need it.
- Easy cross system auth. If I want to build something using separate services, like a front end in one tech stack and a backend/admin using a completely different stack, Auth0 makes it so easy to share logins, roles, and permissions between the two systems without having to work out how to handle it myself, or within having to run my own third system like my own installation of Keycloak or building my own equivalent to it.
I am currently using Auth0 which has all the cool functionality of logging in with 3rd party services, user management, and so forth. I think I am paying them $25/m to use it, something fairly trivial but non-zero.
If I were getting started with logins again, I'd say I could pay you $250 one time just to download all the code, and roll it out on my own systems in minutes. This way I'd have user auth with easiest setup, and no need to reinvent it on my own. Probably.
But, are you just testing things, or is Login.land real? Since your own login system asks for password, instead of email-based auth like you are showing in the screenshots, I suspect that maybe this is just a test :)
Definitely early stages – mostly looking for feedback on the landing page / demo!
Agree that it’s hard to compete with more full-service solutions like Auth0/Firebase. Maybe there’s some variant of this, like self-hosted, that could work :)
It’s not free if you ask for a share, therefore the title is misleading. Maybe title “I built a simple login service” would be more fitting. However, I would need to question simplicity as checking your email is far away from simplicity UX wise.
I wouldn’t use your service if you would pay me to use it. Comparing your service with Stripe is just ridiculous...
I tried setting up an account and got a Firebase error, but generally the answer is no. Sorry.
I'd have to have faith that your implementation of the login flow is more secure than one I could build or get elsewhere. Any weird security smells (like the login page differentiating invalid user email address from invalid password and leaking Firebase errors to the user) are going to lead me to believe that the code hasn't been reviewed from a security perspective.
Thanks for the feedback! This is definitely early stages – mostly looking for feedback on the product and landing page, but I’m definitely embarrassed you ran into that Firebase error! I built the admin side using Firebase auth to get started, but have been planning to move it over to Loginland...
Why would the Login website redirect to Loginland instead of just sending the email directly and displaying an "please check your email" popup? One less page load.
Why would the email redirect to Loginland, not to the original website? OK maybe that's absolutely necessary because of some invasive anti-privacy user tracking, but even then, why would Loginland website tell you to close the window and go back to the original window (what if the user closed it already??), which would only then redirect to original website?
109 comments
[ 3.1 ms ] story [ 179 ms ] threadIf so i don't consider it interesting.
I would consider very interesting something similar to firebase authentication without having to include all the google privacy killer stuffs and for free.
(Edit: i didn't read the text where you explain how you make money)
Does the pricing model make this less appealing to you? Open to adjusting it!
As an alternative to a fixed percent, I'd feel a lot better about a model where the fee gets progressively less with a larger amount of users. This may or may not be a personal thing.
5% on payments might be OK until things starts to take off.
Source: I've helped launch a successful business with Shopify and Paypal 10 or so years ago. Maybe could have saved a lot in fees but that solution was so nuch easier than the rest that it was easily worth it.
Edit: the webshop and payment solution was later changed to something less expensive.
While it's interesting that you're thinking outside the box on pricing models, I would personally never signup for a login service on a revenue sharing basis - I'd much prefer a monthly fee (the standard SaaS model). The percentage also seems way to high in comparison to the value-add - Stripe, who actually process the payment, are taking less than you.
Having said that, I don't think I (or most of HN) would be the target market for this kind of login service.
But I wonder if you can find some kind of niche. Something for individuals and micro businesses that have no tech chops and just want an easy way to sell stuff. For that though, you'd need to go further than login, perhaps turning it into a WordPress plugin (or for another platform), and doing something to provide sales through Stripe, so the user doesn't have to build that themselves.
Implementing email login on top of that is probably as easy as integrating with an external service, without the risk and the concerns about leaking user emails.
Paying a fixed fee might work, but if you start charging per single user, it's problematic. I can see some value if it's per bundle of users (e. G. Every 10 users the pricing increases)
It’s not trivial. It requires some knowledge to do it well. Off the top of my head—choice of unique identifier, password complexity rules, hashing best practices, registration flows, recovery flows, abuse detection, markup hinting for password managers... I could go on.
Edit: Also, after clicking on "Get Started", the first field (email) should be in focus so the user can start typing, without having to move their mouse and click it first.
Edit 2: I love the simplicity of this tool. The interface is pretty good (but not yet great). How can I contact you?
- for trivial projects, I don’t want them to stop working one day
- for more serious services, moving login to a third party is a huge risk. The upside isn’t worth the risk. Even if it did your pricing is way too expensive, but that could be fixed.
Is there a price point at which you would consider using something like this?
If my app is small, I'll roll my own or use the free tier from Auth0 or Okta.
If my app gets big, I'll roll my own or pay for Auth0 or Okta.
Like a lot of SAAS ideas, a login service is: too critical to trust with an unknown, already a mature SAAS offering elsewhere, and easy enough to implement yourself if you don't want to pay for it.
I'd rather set up login functionality on my own server. If you use a third party service, their downtime becomes your downtime. Worse, you're injecting another company into your relationship with your users. If that were necessary, I'd choose one the customer was already familiar with, like Google, Facebook or Twitter.
Setting up login isn't very difficult and libraries exist for most webdev languages to make it even easier. It's definitely not worth 5% of my revenue.
Browsers could implement a service that backs up your personas and syncs them across your devices. Ideally the syncing should be cross browser too and allow me to use my own servers for this if I choose.
Unfortunately, it was shut down in 2016 due to lack of interest. (Coincidentally, I just spent this past week hacking on its source code.)
You're suggesting some different backend details, but the UX you describe is already in place.
With the browser acting as your user agent, it can manage multiple contexts (work, personal) and let you choose which is sent to each site, without the need for separate browsers for each.
As an added tangent, consider that browsers are one of the few places where we can do things like "temporarily log me out of everything" (Incognito Mode / Private Browsing). They have some level of sophistication in session management already.
I would go even further than this, and say that a cryptocurrency might be among the best ways to build a universal login system. Imagine an Ethereum-like coin where the wallet is the username, and you spend the coins while authenticating, gaining privileges, and the blockchain stores your public info like a username and avatar that you can bring to any website.
What is a better solution than building a tamper proof workflow in the blockchain? Examples include:
1. I sign a contract and the notary signs and uploads a copy to the blockchain to validate the contract contents, that it was signed and by whom, and when.
2. An auditor validates a piece of evidence a client provides that proves its in compliance with a particular control in some regulatory framework. The auditor uploads a SHA256 hash of the evidence in a transaction memo to the blockchain to validate against later in peer review, a lawsuit, etc.
Edit: My examples here refer to a valid use case of a blockchain and not cryptocurrencies which is what you mention, but based on context of this discussion it looks like we all actually mean blockchain and not necessarily cryptocurrency.
Blockchains have several uses but to date they are narrow. Everywhere outside of their core use cases (essentially contracts or keeping track of tokens of value) they are a hindrance. Blockchains are also hugely inefficient by design (if they were they’d be easy to crack or to perform a 51% attack on), so when you are communicating with a single third party which you trust to provide a service to you, you absolutely do not need a blockchain. We have seen time and time again people trying to throw this solution at all the problems from DNS to buying groceries and yet the only solutions still worth talking about remain cryptocurrencies. Turns out well defined client/server APIs and databases actually do work about as well as anything else.
In the spirit of discussion, what could you do if you involve a blockchain in logging into GMail that you absolutely cannot do without it? If the answer is nothing, then there is zero reason to go down that path.
> crypto currencies are a good solution for one thing only: electronic currencies.
You contradict yourself by stating above you believe there's only one valid use case for blockchain, but in your most recent comment you obviously admit there are several valid use cases (though admittedly a limited number). Maybe your initial comment was meant for emphasis and not literally that you believe there is only one use case, but be careful using quantifiable verbiage or hard numbers to portray emphasis without explicitly stating that's what you're doing, your credibility gets called into question when doing so.
That being said, if this was /self hostable/, I'd see myself using it on a few projects.
HN ‘markup’ diversity is always a joy for the punctuation mark enthusiast.
\Hooray for markup/
Then I've seen lots of people offload that to Auth0 or other managed services.
Managed services like Auth0 are a great alternative, although Auth0 is one of the more expensive ones. For small apps I found Firebase Auth to be great, for larger projects things like Amazon Cognito or Azure AD B2C are probably the better choice (although Azure AD B2C still doesn't support custom domains). They are worth a try imho, since Amazon as well as Microsoft offer a generous free teir (50k MAUs for free)
- If I cant make enough money per user to even pay for Auth0, why am I working on this?
- Auth0 provides more than login, its got logic related to token re-validation, signup pipelines, social platform integration, etc... sure, I could build each of these as I needed them, in fact I did previously build them for myself. However by using Auth0 I know in advance that all this kind of functionality will be available when/if I need it.
- Easy cross system auth. If I want to build something using separate services, like a front end in one tech stack and a backend/admin using a completely different stack, Auth0 makes it so easy to share logins, roles, and permissions between the two systems without having to work out how to handle it myself, or within having to run my own third system like my own installation of Keycloak or building my own equivalent to it.
If I were getting started with logins again, I'd say I could pay you $250 one time just to download all the code, and roll it out on my own systems in minutes. This way I'd have user auth with easiest setup, and no need to reinvent it on my own. Probably.
But, are you just testing things, or is Login.land real? Since your own login system asks for password, instead of email-based auth like you are showing in the screenshots, I suspect that maybe this is just a test :)
Agree that it’s hard to compete with more full-service solutions like Auth0/Firebase. Maybe there’s some variant of this, like self-hosted, that could work :)
The page leading to login is a bit too plain. Makes more sense to point to /login instead of https://login.land/admin
I'd have to have faith that your implementation of the login flow is more secure than one I could build or get elsewhere. Any weird security smells (like the login page differentiating invalid user email address from invalid password and leaking Firebase errors to the user) are going to lead me to believe that the code hasn't been reviewed from a security perspective.
Why would the Login website redirect to Loginland instead of just sending the email directly and displaying an "please check your email" popup? One less page load.
Why would the email redirect to Loginland, not to the original website? OK maybe that's absolutely necessary because of some invasive anti-privacy user tracking, but even then, why would Loginland website tell you to close the window and go back to the original window (what if the user closed it already??), which would only then redirect to original website?
Seems like a lot of ceremony for nothing.