>Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it

>Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation. On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.) Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties. In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.