My Experience with OAuth.io

A couple of weeks ago, a new service – OAuth.io – was announced that claimed it was going to make it much easier to work with a variety of providers who offer OAuth for their authentication mechanism.

During the announcements, they were doing the usual and taking emails for beta invites. I went ahead and registered – 8BIT had a small project in the pipeline that would be perfect for this should the time sync up for it – and looked forward to trying it out.

To be fair, I rarely get my hopes up with online services. They frequently over promise, under deliver, and are then bought out or eventually sold.

But hey, it was free, it was new, it sounded good, so why not, right?

Now that I’ve actually put it to work in a real world project, I thought I’d share my thoughts on it.

OAuth.io (or “OAuth That Just Works”)

OAuth.io
It just works – or does it?

So the use case that I had specifically for OAuth was this:

  • 8BIT was going to be revamping our GitHub community
  • We wanted to make sure it was as easy as possible to join the GitHub team as possible (1. Insert Quarter 2. Avoid Klingons).
  • To that end, we wanted users who had a GitHub account to be able to click a button and automatically be associated with the team we had created on GitHub.

Sounds easy enough, right?

The thing is, GitHub uses OAuth for authentication, I had just gotten my OAuth.io invitation, so this was the perfect candidate for trying out the service.

The 8BIT GitHub Community

8BIT GitHub Community

So when building the 8BIT GitHub Community service started, we used OAuth.io to wire up the simple Join Now button to OAuth.io which, in turn, was wired up to GitHub’s OAuth authentication mechanism.

It made it incredibly simple to do, too.

So here’s how we actually went ahead and implemented this solution.

1. Create an OAuth Application

Once you sign into OAuth.io, you need to create an application which will in turn generate a Public Key (which you can see below), and then you drag the application(s) that you want to associated with said public key into the container that you see below.

OAuth Public Key

Obviously, I only had a need for GitHub, so that’s what I selected.

2. Create a GitHub Application

Next, I had to create an application within GitHub.

GitHub Application

There’s no need to dive deeper into the application you see above as it shares two pieces of information that are required (but shouldn’t be shared :)):

  • Client ID
  • Client Secret

This is the information that will be used when making requests to GitHub through the application.

Then, within the GitHub application, you have to provide a callback URL for OAuth.io. To do this, you simply provide https://oauth.io/auth.

3. Install The OAuth Library

At this point, you’re ready to bind all of this together in your application. OAuth.io provides everything you need to do this, but it’s a simple matter of including the JavaScript library in your page:

<script src=”oauth.js”></script>

And then you initialize the library with your public key:

OAuth.initialize(‘YOUR-PUBLIC-KEY’);

From there, you’re free to begin implementing whatever calls your API requires. For me, I used cURL and the GitHub API documentation to implement what I needed.

Of course, YMMV based on the application.

So is OAuth Worth It?

With my experience this far, yes – absolutely. I’ve already got some ideas for future applications that are centered around using this as the cornerstone of the authentication process.

But until then, I highly recommend getting in on the service and tinkering around with it.

9 Replies to “My Experience with OAuth.io”

  1. Very interesting, I was thinking just last week this would be a cool service to have around. Nice to see it actually exists!

    Can you clarify how it works in terms of integration? Surely I don’t just add a <script></script> tag and then initialise with JavaScript, right? I mean… if the public key is all you need, and it’s right there in JavaScript, that doesn’t seem very secure…

    1. This is a fantastic service – I love it.

      The public key is fine, too. After all, it’s public :). The Client ID and secret keys are provided by the service provider (like GitHub) so that’s the stuff you gotta keep close to the chest.

      1. Appreciate the reply, Tom. Your tuts+ articles are excellent.

        It’s very useful (at least for me) to know that you’re not using social login. Why is that? Just curious. The adoption rate of social login still seems rather fickle.

        As we’re a bit off topic, I left my email address in case you want to discuss further.

        1. It’s very useful (at least for me) to know that you’re not using social login. Why is that? Just curious.

          Partially because I’m not that big of a fan of tying all of my logins together via a single service that I don’t pay for – I’m always a bit skeptical about that.

          I’d rather just use my email address (which I tend to think is everyone’s best form of identity on the web) as my ID than my Twitter account, Google+ account, or any other account.

  2. In your case, and especially for blog sites where people leave comments, dropping an email address attached to a Gravatar along with your comment is about as good as it gets, offering visual identity and contact all in one. I wouldn’t recommend social login in place of that. In fact it’s what I still use for my comments at GlassOcean.net, but for other things such as communities like StackOverflow, eSports teams, or schools and curriculums where users collaborate and need to be managed, I think social login offers some value and helps improve the user experience.

    Some social login systems actually require the email address for matching the third-party user to a WordPress account, so I guess both methods can be kind of similar in that respect. But if you ask me, doing social login with a user’s email address is the wrong way to go about it, since an email address is not permanent or unique (although it may seem so) and thus recommended against being used as such in the various OAuth2 specs and provider APIs. And even with a social login plugin, you usually still have a WordPress account tied to it operating behind the scenes, and this account still has a username / password which can be used instead. So if the providers all go kaput (which I doubt will happen), the WordPress accounts are still there. Furthermore, having an email address at any of the providers (Google, Facebook, etc) means you also have a unique id with them which more accurately identifies you.

    Per MIT’s OpenID Connect article:

    “The preferred_username and email fields should never be used as unique identifiers as they can be changed over time and can be recycled for new users.”

    Per a Google security advisory:

    “An attacker could forge an OpenID request that doesn’t ask for the user’s email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn’t notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account.”

    A few other issues might arise with using the email address for social login…some providers do not give away the user’s email address (Reddit, VKontakt, etc) and require special handling in the code (e.g. using a fake email address). And the more info you request from a provider, the nastier the consent screen looks where your users have to click Allow / Grant. Therefore, I’ve chosen not to request any personal info by default (email address, etc) and only request/use the unique id. We can ask users to fill out their contact details during registration, or at some later time. In my previous social login plugin (WP-OpenLogin) I did use the email address as the unique id, but I’ve moved away from that for WP-OAuth so I’m hoping it pays off.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.