Many companies are encouraging adoption of OAuth 2.0, and for good reason. In days where we hear about credentials or sensitive information being exposed or hacked all the time (like here and here), it’s nice to know that using an API won’t make you or your users more vulnerable to attack.
In a nutshell, basic authentication requires a username and password to authenticate and give you access to a user’s account. OAuth 2.0 uses an access token to give you access. The tough part is generating the access token. However, once you have the process in place, it’s quite easy to maintain. As a budding developer myself, I can relate to the fact that basic authentication is well documented and simple to use, but once you have an OAuth 2.0 flow in place, it’s much more secure.
The way it works is:
- The user gets taken from your site (where they started) to ours, and they supply their username and password to us.
- We send the user back to the redirect uri that you specified to us in the first step, and we give you an authorization code.
- You trade the authorization code we gave you for a unique access token for the user.
- You store the access token and use it whenever you need to access that user’s account.
An OAuth example is hosted in my Github account. Just follow the steps in the readme to generate an access token. Please feel free to message me via Github with any suggestions or feedback.
OAuth 2.0 is pretty straightforward once you understand it, but admittedly more complicated to set up than just supplying an API Key, username, and password. The bright side is you don’t have to store a username and password! From a peace of mind standpoint, there isn’t any other widely adopted method that is better.
Constant Contact is hopping on the bandwagon fairly early. At the time this article was written, Facebook’s API was using OAuth 2.0 and Twitter’s API was in the beta phase of implementing OAuth 2.0 support. It’s certainly not going away anytime soon either, so jump in there and start using it! Think about all the usernames and passwords that you won’t have to store in a database…
Continue the conversation by sharing your comments here on the blog and by following us on Twitter @CTCT_API.