OAuth2.0 is a standard that describes a pattern of securely authorizing access to private resources. It’s up to each provider to build its own implementation of OAuth2.0. Now that we’ve covered the basics of OAuth in theory, let’s look into how each of the main three providers has interpreted the standard.
What Do They Have In Common?
These three providers share a lot of things. Since they all implement the same standard, many things are the same. However, it’s the differences that trip people up. Unless you know what details are part of the spec versus implementation details, you may be surprised when switching from one to the other.
All three of these, at a base level, are going to implement the steps that we highlighted in our previous article on introducing the concepts of OAuth. However, there are going to be differences that will be highly appreciated by all of us.
Let’s explore what these are.
There are several things that are different, and various steps that will need to be taken by each developer before they’ve integrated with OAuth, the flow, and the API. First, you’ll need to register your app with Google, Microsoft, and Yahoo.
This part of the process is basically identifying your app, along with registering your brand name and your home page URL and uploading your logo. These are each provider’s baseline requirements to learn a little bit about your app.
All three providers also require that developers register the scopes that their apps will use. A scope is a permission that your app will request from a user. Scopes can be described as a verb and a noun. “Reading profile data”, “modifying contacts” and “sending emails” are typical scopes written in English. Scopes are similar to APIs but differ in that they specify what actions the client is allowed to take. The API will allow the client to access certain endpoints as long as the correct scopes have been granted.
Specifying scopes ahead of time is a security feature that ensures that even if your credentials or access tokens are compromised, a malicious app cannot request more access than what was originally intended.
Google’s registration is the most involved, so let’s start there.
Google goes quite a bit further and adds a request for other details such as your app’s home page and privacy policy, along with having your app name and logo verified by Google. Even if you’re not using their sensitive APIs, Google still needs to verify your app to confirm that your brand is legitimate. They do this manually, which means a human actually looks at your homepage, reviews your privacy policy, and compares that with your logo and what you’ve stated as your brand name. They also confirm the redirect URL that you’ve registered with them.
These hurdles from Google are universal for any apps. However, there are additional scopes of access which can require additional information. Scopes are the permission to which you’re requesting access. At the most basic level, you find things like the current user’s email address, name, and profile information about the current user. With that, you can use the feature “Sign in with Google,” which is a button you see on many websites.
The second level is when you’re accessing scopes that are considered sensitive, things like the Contacts API and Calendars. Sensitive scopes require additional verification where Google will ask you to justify why your app needs the data. CloudSponge customers need to navigate this level of verification and it’s something that we help with.
Then at the highest level are Restricted scopes. This is required only for apps that request access to Gmail or Google drive functionality. Approval for access to restricted scopes is the same as for sensitive scopes with the addition of a third-party audit of your app. At this stage, an outside party must verify your account. This external verification will cost at least $10,000 and can take quite a bit longer. Google is very protective of anyone attempting to send email through their service.
Google’s OAuth verification process is there to protect users’ data by ensuring a higher level of accountability from what we are used to. It’s a positive step towards building trust with users of our applications because they can know that Google has vetted any apps which are requesting access to their sensitive information.
Even so, it’s frankly a PITA for developers to navigate the OAuth verification process. The most important thing to do is to monitor your email. Google currently uses email to manage all communications with developers. If they want more information or want you to make some changes for them, they’ll just send an email. If you lose it in spam or promotions then you won’t know that the verification process is waiting on you. It’s frustrating, but you won’t see any changes in your OAuth project to indicate that you are holding up the process.
Microsoft
The process for Microsoft is equally as complex as Google’s, but without the manual verifications. That’s the nice part about it. It takes very little time to set up a developer account to use with Microsoft’s APIs. You can deploy it right away with only one automated verification step, which is a domain ownership self-verification. This step only takes a few minutes typically, since you’re not waiting on them to do any reviews of your data.
Another nice aspect is that you can access multiple different products with Microsoft. At long last, they’ve come to a place where all these different products are accessed by engineers in the same way through the back end. They’ve unified their Outlook.com and Office365 APIs; and Outlook.com was a previous unification of Hotmail, MSN, Windows Live, Passport, and any number of other services. 🤪
In case you weren’t aware, Office365 codes can be extremely long. This is just a bit of knowledge on your app end; that you’re able to handle very, very long codes that come through. When we say long, we mean well over a thousand characters…which expires in roughly a couple of seconds.
The complexity of their UI is on a similar scope as Google, but a bit more complex. It can be quite challenging to navigate, so it’s definitely a good idea to follow some other examples. It’s not exactly what we’d call a user-friendly experience.
Microsoft does not require manual verification but it does encourage an automated domain ownership verification. This is a typical domain verification process where you upload a static file to your site and Microsoft confirms that it is present. Once you’ve completed this step, they’ll remove the subtle verbiage warning users that your app is “unverified”.
Microsoft wants you to indicate the scopes that your application will use when you register. When your app sends the user to the OAuth flow, it can specify any of these scopes in the request. This allows your app to request only the scopes that are needed at any given moment. It’s considered best practice to send the user through multiple OAuth flows if necessary. For example, only request their personal data when signing them in. Later, when your app wants them to share their contacts, send the user on another OAuth flow to request access to read their contacts. This is preferred to requesting all scopes at once because it doesn’t give the user granular control and it can overwhelm them.
Microsoft access tokens can be used the same as other providers’. But they also keep some secrets. The access token response includes an id_token which contains the user’s profile data encoded into it. In this way, Microsoft’s OAuth doubles as an authentication service. Pretty slick.
Yahoo
Yahoo is the simplest and least flexible out of the three providers we are looking at today. It’s incredibly easy to set up an OAuth project. The downside is that you specify in the project all the scopes you’re going to request access as part of the configuration and there is no way to request fewer scopes when you have the user present. At first glance, being unable to request fewer permissions may not seem like a problem, but as we’ll see, it goes against best practices of requesting the least or minimum permissions.
It is best practice to request only the permissions that your app requires in order to meet the current objective. For example, you should ask for permission to their profile data as they sign-in. Later, ask for permission to read their contacts when they are inviting their friends to connect. Best practices dictate that each time a user is presented with a new access request that aligns with their current expectation.
However, Yahoo doesn’t allow for this and requires that you ask for all the scopes upfront. Depending on your app’s needs, this can mean hitting extra resistance from users who are nervous about granting access to their contacts as they first sign in. Slow down!
Yahoo also doesn’t permit you to change the scopes associated with your OAuth project. So if your app changes down the line, you have to create a whole new project, and throw away the original.
In that way, Yahoo is quite inflexible. If you want to have access to the user’s profile information, you must specify that in your Yahoo developer account. If you decide later that you want to access their contact information, you must use a whole different Yahoo developer account and ask for all those permissions again. So basically you have to be clairvoyant about your future requirements when you start the integration with Yahoo.
Not all OAuth implementations are equal. There are subtle differences between the implementations of the big three providers. Even so, armed with a basic understanding of OAuth and by paying careful attention to the differences between each, you’ll be off to the races and integrating with all three and more in no time.
If you are integrating with Contacts APIs with these or other providers, consider using CloudSponge. We’re a single point of integration for these and more. And we’ll support you as you set up OAuth and help you through Google’s OAuth verification.
