OAuth has made it easy for developers to build seamless integrations between their applications and other online services. It’s a great, open toolset used by both small developers and big dev teams in the Fortune 500. From a user experience perspective, it can help make tying multiple online services together painless.

But if you’ve been considering using OAuth in your application, there are a few things to consider before building it in.

It’s an easy mistake to make, but many developers get confused when researching authentication solutions for their application. Part of this has to do with OpenID and OAuth being casually thrown around on developer discussion boards like Stack Exchange as if they serve the same purpose.

There are a number of differences between the two standards, but the main difference is their core functionality. Simply put:

• OAuth is used for authorizing API functions between applications. (Application to Application)
• OpenID is used for authenticating a user with an application or multiple applications.

These two standards are often used in tandem, but serve different purposes. There are some instances when one of the standards has been shoehorned into providing the functionality of the other, but these are rare.

If you plan on using OAuth in your web application, it’s critical that you educate yourself on its security vulnerabilities. Because OAuth is chaining access to multiple services and applications together, a vulnerability at any point in the authentication process can have significant impact.

OAuthsecurity.com is a good resource for keeping up with the latest and most severe OAuth vulnerabilities and how to mitigate them.

Just because your implementation of OAuth functions doesn’t mean it’s secure.

While OAuth is certainly the most popular app-to-app authentication solutions, there are others that may or may not be a better fit for your application and many of them are interoperable (at least on paper) with OAuth.

OpenID’s OpenID Connect is built on OAuth but provides some improvements to functionality and security. If you’re already using OpenID for your project, it may be worth considering.

Facebook and Google have their own standards that are good options for developers working in those ecosystems. It’s worth noting that these (as well as SAML) are really more focused on Single-Sign-On for users than app-to-app authentication. However, they can be used to provide both services.