31–40 of 54 posts
On the other hand, I first thought this was a Facebook thing since it started with "Setup your Facebook API Keys in OAuth.io". Perhaps something like "Setup API keys for the provider of your choice in OAuth.io"?
lost me.
While building https://foauth.org/, I had wondered if it'd be possible to do something like this, but it wasn't really my use case so I didn't really pursue it. I was more interested in people just trying to get access to their own data, so I built a solution for that side of things.
Still, I can speak from experience that wrangling 50+ OAuth providers into a single system is hard enough, and trying to provide a unified API to all of them is even harder. I'm not sure how many sites need to support that many sites, but for people like us trying to simplify the API for others, it becomes a pretty big necessity. As it is, https://github.com/gulopine/foauth.org/tree/master/services is something of a living tribute to the differences between the various service providers.
So yeah, I'll be very interested to see where OAuth.io goes, and for anybody else here who just wants to get their own data (but not run your own service), you might also want to checkout https://foauth.org/.
Basically, Checkpoint is a facade that abstracts authentication into a simple API. You set up Checkpoint with your OAuth keys (for, say, Facebook), then just redirect your app to /login/facebook. Checkpoint will do the OAuth interaction and return to your app with a key that can be used to access the login session.
Checkpoint abstracts the notion of logins into identities and accounts. An identity corresponds to a user, and can have more than one account associated with it. Identities are logically partitioned by "realm", so it's ready for federated installations.
There's no shortage of simple OAuth consumer libraries out there, what I really want to see is a simple way to set up my app as an OAuth _provider_. As far as I know there's nothing out there to make that simple yet.
Vanilla is a Sinatra app, exposes a simple API and user database, and the UI is rendered entirely through webhooks. In other words, it's designed to be a headless system that works in concert with a real app, so that the app itself does not need to implement OAuth or indeed the core account handling.
(Some parts, like the ability to sign up by verifying your phone through an SMS code, are very specific to our workflow, but it's intended to be completely generic, so those things can be changed.)
That said, OAuth 2.0 is very simple to implement. It's pretty much entirely encapsulated in oauth.rb, token.rb and authorization.rb, if you want some inspiration.
Earlier quoted context omitted.
Or even if there was a simple, detailed guide on what your own OAuth needs to do to be secure - and a basic overview of how to implement it (not language specific, just concept-wise).
The TLDR version is: use https and OAuth 2.0, and this guide: https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.m...
Does this service require me to give up my private key for a given API? Seems like a huge security risk to me.
We also support email & password (using the same OAuth API) and Mozilla Persona, as well as take care of headaches like password reset, email validation, and account de-duplication (for example, if a user signs in using Facebook on day one and then email on day two).
Best of luck to oauth.io however -- the simple js approach is interesting.
Interesting. It took me a minute to figure out what you're actually doing here, but once I found the important bit on the page ("Setup your API Keys in OAuth.io"), I can at least be confident this isn't a glaring security concern. :) And yes, that was a legitimate concern when I first looked at it, given how little information is currently available. While building https://foauth.org/ , I had wondered if it'd be poss…