This looks well done. Congratulations on building a cool product!
A word of caution on this as a business, though: this is going to be brutal. You're selling a service that every competent web developer can build. You can save them time -- but not a huge amount of time, especially compared to the prepackaged user registration apps that already exist for common web frameworks. And the customers that grow really big will have strategic reasons to want to move off of your service, in addition to any cost-saving reasons. Maybe over time you can grow into something like http://www.gigya.com/ , which powers registration & social/gamification components for mainly content sites. But to do that you'll need to find a market of people who aren't developers, for whom your thing is a real enabler, not just a time saver.
TL;DR: Unless you're building something technically complex enough that everyone realizes they can't come close to replicating it, don't build stuff for developers. We're stingy and we think we can do anything ourselves in a weekend.
You're selling a service that every competent web developer can build.
Despite being chummy with the founders, I basically said something similar about http://pusher.com/ when it came out. D'oh.. and it's going like gangbusters. I was similarly pessimistic about Heroku too (managing a VPS is eassssy!) but.. no longer. People want to outsource boring infrastructure no matter how trivial it is to implement.
This only works up to a point. I evaluated http://pusher.com for Poll Everywhere, but decided against it because I didn't want a "tax man" between me and my customers.
I'd argue that most of the folks that use Pusher don't do so in a way that's mission critical to their application (there are a few exceptions). If they did, they would scale up to a certain point where they'd want to get off of Pusher and on to a self-hosted push server.
That's precisely where Pusher fell off the horse for me, so our company created an open source streaming service, http://firehose.io/.
That said, would anybody be interested in a hosted version of Firehose? The "end-game" of a hosted service would always be to run the open source version of this service on your very own servers, and stop paying the middleman tax.
You're selling a service that every competent web developer can build…
You say this as if it were a bad thing. I like outsourcing things that, in an emergency, I can easily replace.
What I hate is buying a service that has no competition (so I can't easily switch to a different vendor) and that would take hundreds of hours to duplicate (so I can't easily switch to my own implementation.)
> You're selling a service that every competent web developer can build.
This is true, but nobody ever does. Seems like most of the "Show HN" links we see here require Twitter and/or Facebook for login and offer nothing else.
An OAuth provider that's JUST an OAuth provider is pretty welcome to me.
ClickPass is effectively this, although they were OpenID. I don't think it worked out too well for them but it was several years ago, so they may've been too far ahead of the curve. HN used to use them as a sign in provider.
I think most sites rely on Facebook/Twitter logins, not because it is easier than adding in their own system, but because users don't want to have ANOTHER login in, and it allows for easy shareabliity.
"You're selling a service that every competent web developer can build."
As people are realizing that lot of these websites do not follow good security when it comes to user storage, slowly the trend might be to use standard third party systems. Agreed that most users do not know what bcrypt means. But most users do care if their passwords get hacked becuase it was easy to do so (clear text storage etc.).So yes, you can build a user system easily but can you make it trustworthy, secure ? So again, I think this idea probably sounds a little crazy in 2012 but you never know 5 years down the road.
I come from a SaaS background and agree with everything you've said. We do have a roadmap that we believe will overcome this challenge however. In the interest of launching early and often, we decided our MVP was to focus on being a white-labeled OAuth provider. But we do want a way for people to tip their toe in the water quickly and easily.
Its not about whether you can build it, of course you can. Its about choosing to build things that solve your core problem. Time is money, and your money is best spent on the original aspects of your idea that do not already exist.
I agree, but this can be a great tool for MVPs, POCs and anything you want to build fast (unless you just copy paste your previous startup's code base and change the logo, but you need to have done it before to copy, or spend money to build it, even a weekend saved is worth sometimes...)
I'm confused. Surely there is still a token or something for the authenticated session used on the original site. Wouldn't this leave the user's session open to hijacking if they didn't implement https on their site too?
I understand this may be less of a concern for some applications, but it seems bad practice to spread the idea that https is only important for an actual login step.
You know, you HN guys are super buzzword and design blind. This company slaps "bcrypt", "SSL", and "open source" on a decently designed bootstrap page and the response is "this will totally work!" Sad.
I found these problems in just scanning through some links off that first page. Seems like this crowd would be able to pull up more, and definitely shouldn't just saying "Oh SSL, well then that whole thing is totally solid."
A lot of our friends have created startups that don't offer email and password, and just use Twitter or Facebook for user accounts. At our previous company, we found a large majority of users still prefer to use email and passwords. So, we decided to try and make email and passwords as easy to use as Facebook Connect.
I liked the idea, having implemented our custom login some months ago. Before that we relied on Facebook Connect and Twitter auth, and it's true that some people prefer to use email.
Feedback: I couldn't find a pricing page nor a call to action button to (pay and) start using your service.
edit: I decided to take an another look and I found the pricing section scrolling to the bottom. Why not a link in the top nav bar?
I may well have used this if you had launched a month ago. At this time I have my own system stitched together with the integrated mulit-OAuth-provider API from OneAll.com. I'll give you the same advice I'd give them: since you're pitching to busy, new, or possibly-competent-but-slow developers, I would encourage you to take the next step and see what else you can get done for me as a neophyte developer at the same time. I'd really appreciate an MVP starter kit -- a single download that includes an ideal usage of your code already wired in, the first thing I drop into my new site's FTP before doing any real work. In particular I'm thinking of a Twitter Bootstrap framework with all the appropriate supporting files all rolled up. One config file to point to my local MySQL instance, Facebook app, etc. It's great that you've made it straightforward for a competent developer. Please make it straightforward, safe, fast, and easy for a soon-to-be-competent one.
Already implemented (but not documented yet) is an XMPP push notification API that consumers can use to send notifications (using Blather, EventMachine, Redis PubSub, Foreman). Also several roles (scopes) are implemented to allow everything from "per-consumer-app-uid", "global uid" up to push messaging (for people interested in privacy)
An Omniauth plugin to implement PiratenLogin is available here (thanks to the awesome doorkeeper gem):
This seems like a really good idea. Writing login/auth/password reset/etc crap for the last 10 years has gotten tiring. The problem is that people are necessarily going to have to put a lot of trust into you and your service. For example, if your service goes down, can my users log in? Trust is going to be the biggest issue, but we've seen these walls fall down before if the pain threshold is high enough.
Missed the bcrypt part. Regarding providers - I've seen AWS, but that may mean a lot of things and a lot of ways to execute. If I want to evaluate how stable will this service be, it doesn't mean anything really (it could be one instance with the whole storage going away if it crashes). Geographical location may matter too depending on what kind of users you handle.
Hi -- thanks for the questions. We want more docs online, but haven't done a full write up yet. In short, we don't have an SLA, but we know enterprise will want that so we're working on it.
Someone else responded to some of your questions. Here is some more color: Only employees can view the data. Authenticated admins can view their own data (but not password hashes yet -- we want to use MFA for those requests to export). Passwords are never stored. We use the industry standard BCrypt (salted hash). We're using DynamoDB for storage. Our primary location is N. Virginia. We use MFA on AWS to secure everything (http://aws.amazon.com/mfa/). We backup several times a day and store backups in different regions on similarly secured S3 (uses the same MFA). We have tested the backup and migrated to another data center entirely (AWS Oregon). We are also 100% https, using hsts, and all of our cookies are HTTP Only and set to secure (http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly). I think this answers most of your questions. Happy to answer any followups as well.
Somehow I don't like this statement: "We've implemented https so you don't have to."
Just because authentication itself is secured over SSL doesn't make the whole site secure enough. For some things, it might suffice, but it's not something you should publicly recommend IMHO.
I have personally thought about this idea as well at times. User management is something that every web based business needs. So the concept of UAAS (user-as-a-service) is definitely interesting. But the biggest question is: how can you let one of the most critical aspects of your business (your users) in the hands of a third party. Have we matured enough to try this ?
I guess this could work for those who don't really count their users as their primary assets (and would otherwise outsource authentication to Twitter or Facebook), but I don't really see this getting wide adoption among companies that are building and cultivating their own user bases.
It'd be curious to see how this will evolve and develop though, that's for sure.
A number of people have mentioned this, so thanks for bringing it up here.
We're building a complete export, and use BCrypt for password hash storage. This means you can migrate off our service at any time (unlike Facebook & Twitter).
Thanks for the feedback all -- we're probably going to throw in a calculator for people who want a quick and easy answer about pricing for their service.
Interesting take. But as a user, you are making me do an extra step because ultimately, we all want to know how much total ? I dont care if you charge 0.0000001 per user. I want to know whats the "grand total" that my wallet has to come up with.
But doesn't that depend on how many users you add? Would you rather pay $10 for up to 10k users, regardless if you have that many or a few cents as you work your way there?
I like the pay as you go pricing model over flat rate. Reminds me of amazon.
Thanks for the feedback. Right now we are "silo-ing" all of our client's authentication data. We have gotten feedback that some people would like to be able to share authentication credentials (like Facebook, etc.) -- but it's not clear everyone wants that just yet.
My favorite part about this is the built-in event tracking. You can easily see even detailed things like whether people failed the signup, maybe one degree of tracking beyond, say, Mixpanel. Hopefully, this can easily be integrated into larger systems like the same.
I love the built-in SSL. --My only real concern, and I'm sure reviewing the docs further will help me understand more, is how I mirror users on my app so that I don't have to query the REST API for user accounts.-- EDIT: Looks like it's automatic. Even cooler.
Yeah, SSL was a huge pain for us in the past, so for simple services, this makes SSL optional rather than required.
And we're following Facebook Connect's OAuth flow exactly -- so storage of the user locally on your service would be identical if you've already implemented FB OAuth.
Sounds like good idea to me. I currently only use Twitter and Facebook in my prototype, but once we start user registrations, this is the service I definitely want to try first.
> DailyCred integrates just like Facebook Connect but with your branding. You also own your users' data and can take it with you at any time.
The context isn't clear if this means my OAuth credentials or my Facebook profile information but you shouldn't invite the question that the app owns my Facebook data or that they can access it when I'm not online.
I have been looking into this recently and it seems that a lot of sites are using OAuth2 over OpenID.
Even when they are using it as a simple authentication mechanism (The scenario that lots of "OAuth2 vs OpenID" posts, blogs and tutorials say is where you should be using OpenID )
Since this site is also using OAuth2 instead of OpenID can I ask for your reasoning?
Congrats, I was thinking about building something similar, with idea to be bridge service for young startups, so they can focus on other features. Still I was not sure how viable it would be, which is why I am happy you did it and I wish you all the best.
I am using this on my website http://playmysurvey.com. Many users have declined to sign-in with facebook, so we had to offer an alternative sign-up and this was piece of cake.
Seems like a well-done service, but I would think that user management is far too strategic for most businesses to hand off to a third party.
My impression is that most people use OAuth-type authentication schemes not because they are worried about the complexities of user management, but rather that they want to gain access to the resources that those enable. In the case of Facebook and Twitter, authenticating with them provides access to new distribution channels, which is really the entire reason they are interesting in the first place.
I think these infrastructure start ups are a good idea. We can build an app\site faster by concentrating where it matters most. Please reply to my comment with the infrastructure providing company that you know. Let's build the list. Googling is not going to be an easy task for this.
Awesome service! I absolutely HATE doing authentication with Devise. And doing signup/login is boring as hell. Definitely going to use this for my new project.
I genuinely hope Dailycred takes off and be around for a long time to come.
A word of caution on this as a business, though: this is going to be brutal. You're selling a service that every competent web developer can build. You can save them time -- but not a huge amount of time, especially compared to the prepackaged user registration apps that already exist for common web frameworks. And the customers that grow really big will have strategic reasons to want to move off of your service, in addition to any cost-saving reasons. Maybe over time you can grow into something like http://www.gigya.com/ , which powers registration & social/gamification components for mainly content sites. But to do that you'll need to find a market of people who aren't developers, for whom your thing is a real enabler, not just a time saver.
TL;DR: Unless you're building something technically complex enough that everyone realizes they can't come close to replicating it, don't build stuff for developers. We're stingy and we think we can do anything ourselves in a weekend.