
Show HN: LoginBox – Authentication, payments and memberships from a single box - ipapikas
http://loginbox.io
======
buro9
I currently use Mozilla Persona to auth 50k users, with at least 15k sign-in
events per month over 300 websites.

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.

~~~
ipapikas
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!

------
zoomzoom
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.

~~~
OJFord
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?

------
hijinks
If you support payments, your marketing site should really be https

~~~
ipapikas
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.
;-)

------
outwork
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!

~~~
ipapikas
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!

------
filearts
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](https://auth0.com/lock)

2: [https://auth0.com/docs/rules](https://auth0.com/docs/rules)

~~~
ipapikas
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!!!

------
neilellis
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

~~~
lucaspiller
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.

~~~
neilellis
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

~~~
lucaspiller
Makes sense, thanks for the explanation!

------
harryf
Why username / password? On mobile this is a dead approach. See
[https://docs.fabric.io/android/digits/digits.html](https://docs.fabric.io/android/digits/digits.html)

~~~
tarr11
Why is this better?

~~~
harryf
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.

------
rdegges
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

~~~
ipapikas
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! ;-)

------
r1ch
The background image choice clashes with the font color which makes it hard to
read. [http://i.imgur.com/epctfAh.png](http://i.imgur.com/epctfAh.png)

Any plans to support subresource integrity?

~~~
ipapikas
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.

------
RyanZAG
What's the difference between the 'Two-Factor Authentication' and 'Multi-
Factor Authentication' of the different price plans?

~~~
ipapikas
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.

------
squiggy22
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.

~~~
jtreminio
PHP's Symfony2 has the FOSUserBundle:
[https://github.com/FriendsOfSymfony/FOSUserBundle](https://github.com/FriendsOfSymfony/FOSUserBundle)

------
ash11th
The "Terms of Service" and "Privacy Policy" links on the signup form are
broken

~~~
ipapikas
Thanks for letting us know! We will fix those links as soon as we have the
documents ready. We just added a more explanatory text!

------
wittjeff
How does this compare to the Google Identity toolkit
([https://developers.google.com/identity/toolkit/?hl=en](https://developers.google.com/identity/toolkit/?hl=en))
?

------
ronreiter
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.

------
pvinis
when i press the "get early access" button on iphone chrome, is crashes.

~~~
ipapikas
We don't know why this is happening and we are on it. Meanwhile please try a
different browser! Thanks!

------
voctor
no HTTPS...

~~~
ipapikas
We just launched the website and we are getting our certificate right now.
However, the underlying api is on HTTPS. ;-)

------
ukandy
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.

~~~
jtreminio
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.

~~~
ukandy
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.

~~~
ukandy
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.

