Show HN: LoginBox – Authentication, payments and memberships from a single box
loginbox.io
loginbox.io
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.
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 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.
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?
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!
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.
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
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
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.
Twillio also enables this if you want to roll your own - https://www.twilio.com/blog/2015/01/mobile-passwordless-sms-...
All the best! <3
Any plans to support subresource integrity?
The SSL issue, however, needs to be fixed ASAP.
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?
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.