Show HN: LoginBox – Authentication, payments and memberships from a single box(loginbox.io)
loginbox.io
Show HN: LoginBox – Authentication, payments and memberships from a single box
http://loginbox.io
48 comments
1) You have a point. One 'Who we are' section coming up. :)
2) If you mean you have 1000 users across all websites you could create a different account for each of them. We know this might become a pain to manage so we are planning to allow users to manage multiple websites in future versions an each will be priced separately.
3) If you're talking about allowing users to give different access levels to their users then we already have that on our roadmap.
4) If anything happens to us we will be providing assistance to website owners to recover their data. We also support user export at any moment and this should cover you.
5) We verify users on signup by asking them to click a link we email to them. Social login also guarantees email verification.
6) Caching and custom login pages is a feature we support at the moment, so that you will be able to avoid calling the loginBox all the time. We are working against DoS attacks in parallel.
7) As long as both accounts have the same email you should be fine. We treat social logins as a verification for the email associated with it.
I will email you so we can meet and talk about them! Thanks a lot!
2) If you mean you have 1000 users across all websites you could create a different account for each of them. We know this might become a pain to manage so we are planning to allow users to manage multiple websites in future versions an each will be priced separately.
3) If you're talking about allowing users to give different access levels to their users then we already have that on our roadmap.
4) If anything happens to us we will be providing assistance to website owners to recover their data. We also support user export at any moment and this should cover you.
5) We verify users on signup by asking them to click a link we email to them. Social login also guarantees email verification.
6) Caching and custom login pages is a feature we support at the moment, so that you will be able to avoid calling the loginBox all the time. We are working against DoS attacks in parallel.
7) As long as both accounts have the same email you should be fine. We treat social logins as a verification for the email associated with it.
I will email you so we can meet and talk about them! Thanks a lot!
The biggest problem with any of these "login as a service" systems is that on the web, you need to be able to set a secure (HTTPS only), server-only cookie in order to provide a persistent login. You can implement that on your own server on top of this using their API, but it makes the amount of work much closer to "rolling your own" than "paste one line of JS on your static html site hosted in s3."
The alternative is to either force a login on every visit, or store a session token in localstorage or similar, where any XSS vulnerability opens your sessions to an easy exploit. Auth0 and Stormpath, which are the 2 of these I have looked at most closely, seem to do the 2nd of those. Not sure what these guys recommend yet but I imagine it is similar.
On mobile, this does not matter as much due to better filesystem access that an app will usually be granted compared to JS in a browser tab, where you can save your API key/JSON web token/etc.
Auth is hard, but the cost-to-benefit of outsourcing seems fundamentally limited at this time due to the storage problem on the web.
The alternative is to either force a login on every visit, or store a session token in localstorage or similar, where any XSS vulnerability opens your sessions to an easy exploit. Auth0 and Stormpath, which are the 2 of these I have looked at most closely, seem to do the 2nd of those. Not sure what these guys recommend yet but I imagine it is similar.
On mobile, this does not matter as much due to better filesystem access that an app will usually be granted compared to JS in a browser tab, where you can save your API key/JSON web token/etc.
Auth is hard, but the cost-to-benefit of outsourcing seems fundamentally limited at this time due to the storage problem on the web.
Login-aaS seems conceptually strange to me.
With a tonne of example code for social logins, why do these services' customers prefer to pay for the privilege of trusting the indirect social login to the provider's service?
I'm very surprised if there isn't an open-source project with similar 'dashboard' etc. that Auth0 offers - and wouldn't the security-savvy guys prefer that?
With a tonne of example code for social logins, why do these services' customers prefer to pay for the privilege of trusting the indirect social login to the provider's service?
I'm very surprised if there isn't an open-source project with similar 'dashboard' etc. that Auth0 offers - and wouldn't the security-savvy guys prefer that?
I built a similar "login as a service" three years ago, and the biggest I came across was that any modern web framework already includes authentication and user management out of the box. And user management that is guaranteed to integrate with the rest of the framework. It was a really difficult sell trying to convince developers to use my service rather than their own framework.
[deleted]
Thanks for the comment! At the moment we are focusing on frontend and mobile so we have to be able to access the authentication tokens from the javascript. However, localStorage is an option we are currently exploring to use instead of cookies.
For mobile we agree that they have their filesystem to store the tokens securely.
If you support payments, your marketing site should really be https
As we replied to a previous comment, we just launched the website and we are getting our certificate right now.
However, the underlying api is on HTTPS. ;-)
Congratulations, it takes a lot of work and time to get this far and launch a set of polished features like this.
Consumer identity offers a very large market segment to sell to and is growing very quickly as an area of focus in enterprises that provide technology to earn dollars from their customers. For those of you unfamiliar with identity management, think of loginbox as twilio for authentication. Historically, companies like Janrain and Gigya have dominated this segment and have focused on selling into Marketing teams with IT as a supporting buyer. Companies like OneLogin are building consumer identity features like this to compliment their internal SSO and provide unification of identities across external and internal user groups.
The name of the game is uptime, be prepared to handle any and all conversations/questions around your architecture, technical operations, strategic decisions to support uptime, and what makes you unique.
Identity is based on open protocols, SAML, OpenID Connect, JWT's etc.. so products start to look very similar, differentiation is difficult but still possible, you'll need to craft your story early or find yourself constantly answering "How are you different from vendor X?".
The payments integration looks great. Companies like segment.io and zapier have proven that ubiquity of integrations can provide huge wins for end users of your product. Start thinking about which ISV's will help propel you into customer bases you wouldn't be able to reach otherwise!!
double congrats!
Consumer identity offers a very large market segment to sell to and is growing very quickly as an area of focus in enterprises that provide technology to earn dollars from their customers. For those of you unfamiliar with identity management, think of loginbox as twilio for authentication. Historically, companies like Janrain and Gigya have dominated this segment and have focused on selling into Marketing teams with IT as a supporting buyer. Companies like OneLogin are building consumer identity features like this to compliment their internal SSO and provide unification of identities across external and internal user groups.
The name of the game is uptime, be prepared to handle any and all conversations/questions around your architecture, technical operations, strategic decisions to support uptime, and what makes you unique.
Identity is based on open protocols, SAML, OpenID Connect, JWT's etc.. so products start to look very similar, differentiation is difficult but still possible, you'll need to craft your story early or find yourself constantly answering "How are you different from vendor X?".
The payments integration looks great. Companies like segment.io and zapier have proven that ubiquity of integrations can provide huge wins for end users of your product. Start thinking about which ISV's will help propel you into customer bases you wouldn't be able to reach otherwise!!
double congrats!
It's a lot to do and think right now (as always for this kind of service) and we have to focus on making our uptime trustworthy and our architecture solid!
This is just our first draft of our page and the loginBox demo is on its way this week along with the beta dashboard. We are going to make it more clear and answer to those questions in advance!
Thanks a lot for all!
Imitation is supposedly the greatest form of flattery, so I would say that this startup is really absolutely praising the design of Auth0's Lock[1].
Indeed this seems to offer a subset of Auth0's identity and authentication services with the addition of payment and membership. From the landing page, the scope and ease of use of the latter isn't very clear.
Integrating payment and membership into an identity service seems like a valuable addition but I wouldn't trade that for a fully extensible authentication pipeline[2] and a proven track record.
1: https://auth0.com/lock
2: https://auth0.com/docs/rules
Indeed this seems to offer a subset of Auth0's identity and authentication services with the addition of payment and membership. From the landing page, the scope and ease of use of the latter isn't very clear.
Integrating payment and membership into an identity service seems like a valuable addition but I wouldn't trade that for a fully extensible authentication pipeline[2] and a proven track record.
1: https://auth0.com/lock
2: https://auth0.com/docs/rules
It's only our first draft and it's natural to have similarities. You can expect big changes and improvements in the future!
As our first landing page for the product, we have to redesign a lot of things and this is exactly why we are here! We want to make it easier for people to understand what services we are providing.
We noticed a demand on payments so we are planning a lot of effort into making it happen.
Thanks a lot!!!
I like the idea of integrated payments and login - I use Auth0 and ChargeBee at the moment. I hope you know what you are getting yourself in to :-) these are two highly complex areas.
The best chance of succeeding in this I would guess is to get funding and scale quickly. I've seen people attack this area before and they basically run out of money and the project hangs. You need to project a lot of confidence and stability while moving fast - so adequate funding will be key.
Good luck, if you nail this hundreds of SaaS startups will be very grateful.
PS: pricing is way too generous, think in terms of revenue.
So a SaaS with 1000 users is getting something like $20K gross a month, with 10K users that's $200K gross.
I'd change your levels to something like
100, 500, 1000, 5000, Contact Us
The best chance of succeeding in this I would guess is to get funding and scale quickly. I've seen people attack this area before and they basically run out of money and the project hangs. You need to project a lot of confidence and stability while moving fast - so adequate funding will be key.
Good luck, if you nail this hundreds of SaaS startups will be very grateful.
PS: pricing is way too generous, think in terms of revenue.
So a SaaS with 1000 users is getting something like $20K gross a month, with 10K users that's $200K gross.
I'd change your levels to something like
100, 500, 1000, 5000, Contact Us
We think that those two areas can be connected and it will very valuable for SaaS startups.
We were thinking about the generosity for our pricing plan, we are considering increasing the prices for the premium and enterprise plans.
Thanks a lot for the feedback!
May I ask what you use Auth0 for? I agree it's easy to do authentication wrong, but it's not that hard that I'd want to outsource it all myself.
Hey Lucas
I'm very happy to share!
So I'm on my 6th or 7th startup attempt at the moment. User management is one of those areas which starts off simple but becomes an amazing distraction. If you're a team of less than 5 people you're sacrificing a huge amount of time on something which isn't core business. When I first started I did everything myself, but after each startup I learnt more and more not to do anything myself.
So in my current project I'm using (amongst others) these startups to replace things I would initially have done myself.
ChargeBee - Billing
Auth0 - Authentication
AWS Lambda - Server logic
Firebase - persistence for the UI
Zapier (the swiss army knife for SaaS companies!)
Surge.sh - static SPAs
Intercom - everything to do with users which isn't auth.
The initial fear of lack of control when using 3rd parties that sometimes SaaS companies have is unwarranted, the odds are against us succeeding in the first place so time spent writing auth stuff etc is time we'll never get back. Even if we succeed we will probably take 2 years to be profitable. That's plenty of time to migrate our systems if we need to - and we probably won't.
ATB, Neil
I'm very happy to share!
So I'm on my 6th or 7th startup attempt at the moment. User management is one of those areas which starts off simple but becomes an amazing distraction. If you're a team of less than 5 people you're sacrificing a huge amount of time on something which isn't core business. When I first started I did everything myself, but after each startup I learnt more and more not to do anything myself.
So in my current project I'm using (amongst others) these startups to replace things I would initially have done myself.
ChargeBee - Billing
Auth0 - Authentication
AWS Lambda - Server logic
Firebase - persistence for the UI
Zapier (the swiss army knife for SaaS companies!)
Surge.sh - static SPAs
Intercom - everything to do with users which isn't auth.
The initial fear of lack of control when using 3rd parties that sometimes SaaS companies have is unwarranted, the odds are against us succeeding in the first place so time spent writing auth stuff etc is time we'll never get back. Even if we succeed we will probably take 2 years to be profitable. That's plenty of time to migrate our systems if we need to - and we probably won't.
ATB, Neil
Makes sense, thanks for the explanation!
Auth0 doesn't just provide authentication, it's OpenID Connect provider which is really where it becomes an attractive option.
Why username / password? On mobile this is a dead approach. See https://docs.fabric.io/android/digits/digits.html
We have in mind that username can be a lot of things including email, a unique username or even a phone number.
It depends on the approach but definitely under consideration in order to improve. Thanks!
Why is this better?
Users only need to remember their own phone number - you send a temporary activation code via SMS to register - as painless a signup as you can get
Meanwhile it sets a higher bar than an email address for fakes signups; as a developer you have a higher degree of confidence that most of your signups correspond to a real person, which can help reduce abuse etc.
Meanwhile it sets a higher bar than an email address for fakes signups; as a developer you have a higher degree of confidence that most of your signups correspond to a real person, which can help reduce abuse etc.
"Invalid phone number". Nice try, but no.
Huh? Digits (for example) supports over 200 countries - https://get.digits.com/international-growth
Twillio also enables this if you want to roll your own - https://www.twilio.com/blog/2015/01/mobile-passwordless-sms-...
Twillio also enables this if you want to roll your own - https://www.twilio.com/blog/2015/01/mobile-passwordless-sms-...
Yeah, it says it "supports" mine (Hong Kong) but whenever I type in my phone number that's what it says.
Congrats on launching! I work at a competing service, Stormpath, but wish you the absolute best! There's still so much room to make a dent in this particular market, especially if you execute really well with polished libraries, etc.
All the best! <3
All the best! <3
Thanks a lot! We will do our best to provide a valuable product and hopefully you'll decide to come and work with us in the future! ;-)
The background image choice clashes with the font color which makes it hard to read. http://i.imgur.com/epctfAh.png
Any plans to support subresource integrity?
Any plans to support subresource integrity?
We'll change the background soon. Thanks for letting us know.
As for subresource integrity, it's in our plans for future versions. Right now we are focusing on making our main features as secure as possible.
What's the difference between the 'Two-Factor Authentication' and 'Multi-Factor Authentication' of the different price plans?
What we actually meant is that Multi-Factor Authentication is the same as Two-Factor Authentication but with multiple options for the second step. We are going to fix it ASAP to avoid confusion.
Thanks a lot for bringing this to our attention.
Does anyone know any open source projects that provide that level of abstraction? I mean, login code, user profile management etc. is so repetitive, I'm surprised that even with all the frameworks there are out there, that none just have drag and drop ready to go functionality for this sort of stuff already.
PHP's Symfony2 has the FOSUserBundle: https://github.com/FriendsOfSymfony/FOSUserBundle
How does this compare to the Google Identity toolkit (https://developers.google.com/identity/toolkit/?hl=en) ?
From a business perspective, the only way to implement login as a service properly would be to integrate it with services like Parse. And then you're also vulnerable to competition from within.
Genuinely like the idea, but wouldn't trust a service that uses PHP on a VPS without SSL. I'm sure you will fix the SSL when you launch, and I'm just a snob with regards to PHP.
Nobody really cares what you think about a third party service using a language you don't like.
The SSL issue, however, needs to be fixed ASAP.
The SSL issue, however, needs to be fixed ASAP.
I have huge respect for PHP, and many years of PHP development under my belt. I wouldn't dream of using it for something pretty heavy weight such a this. Certainly a factor that would come into play for some prospective users.
Running a payment gateway and authentication services is like painting a massive target on your back. The security must be impeccable, one mistake would be a monumental score on the part of a cracker.
A VPS introduces many layers of possible weakness, that could be used a entry points for an attack.
PHP just isn't the right tool for the job. I agree with you, that at this point in time it's secure. I trust that other languages, with smaller, simpler code bases will be more secure over time.
A VPS introduces many layers of possible weakness, that could be used a entry points for an attack.
PHP just isn't the right tool for the job. I agree with you, that at this point in time it's secure. I trust that other languages, with smaller, simpler code bases will be more secure over time.
Without having access to the actual source code, I wonder what you consider heavy weight about it?
If you mean the purpose of the app, PHP is more than capable of handling highly sensitive data if it is written by a capable developer.
If you mean traffic wise, a single VPS can easily handle thousands of requests a second, and if you need more you simply add more inexpensive VPS.
Unless I misunderstood your sentence?
If you mean the purpose of the app, PHP is more than capable of handling highly sensitive data if it is written by a capable developer.
If you mean traffic wise, a single VPS can easily handle thousands of requests a second, and if you need more you simply add more inexpensive VPS.
Unless I misunderstood your sentence?
The biggest problems with login box, a.k.a. drov.io:
1) Trust. Who are you?
2) Pricing. Even with 300 sites, 1,000 concurrent users at any given moment, and fully dynamic sites, the proposed pricing for me of EUR 70 per month is a quarter of all my current costs. The cloud has made things very cheap, and this looks very expensive as a result.
3) Multi-user and PaaS. How could I grant access to the membership and management of one slice of users but not the rest? i.e. my 300 sites are on one platform, each site is typically a non-profit who own their own users... in theory they own their user database and I just host it, they should be able to manage it and for me to query that to apply authorisation within my app.
4) Longevity. If I consider moving things over... what happens in 18 months time if you reach the end of your runway? How could I reverse adopting this?
5) How do I identify a user? Assuming you auth them and then say "you're good", what single thing can I use to identify them that is meaningful to me? Persona returns a verified email for all users, are you able to do the same?
6) Are you static site friendly? i.e. Can the pages with the "Sign-in" box be cached and thus allow me to serve great numbers with little hardware, and does loading a page with a "Sign-in" box always trigger a HTTP request to you (if I'm under DDoS attack, is it going to take you down?)
7) How do you manage "email change"? Or things like "I signed in with my Gmail, but now I want to use my Github"?
Those things weigh heavily. Happy to talk with you about them, I notice that you're in London and so am I. These sites are side projects, not my main gig... just things that linger and that I still maintain.