Why OAuth 2.0?
Our previous method for authenticating was the ClientLogin method, which required users to enter their credentials – username (or email) and password. Developers then receive a token which they can use to call the API without the need to store those credentials, but nevertheless they are required initially, which is not comfortable for some users. Additionally after we launched our developer portal and had to add rate limiting to prevent abuse, we needed a way to distinguish between different apps, so developers were required to use application authentication in parallel with user authentication. This made using the API more complicated than it needs to be.
OAuth 2.0 takes care of both issues at once.
How do I use OAuth 2.0?
OAuth looks like a complex protocol, but it’s really not and because it is so widely used nowadays in its standard form, chances are you already know how to use it if you are a developer. Our documentation provides all the necessary details for you to get started.
How will users benefit from this?
First, it’s obvious that OAuth 2.0 is more secure than having to enter credentials in 3rd party applications. Then come the additional perks:
- New users can register directly in 3rd party apps, because the sign in / registration flow is handled on Inoreader’s side.
- Users can use Google or Facebook login methods to access your app.
- Apps that don’t need to change data can use the new read-only permission.
How will developers benefit from this?
Having new users register directly will lead to more conversions. You won’t need to deal with user credentials anymore, meaning you have nothing to explain, especially people use Google or Facebook login. You also don’t need to use application authentication anymore, because it is handled by our OAuth implementation. Finally ClientLogin will be deprecated at some point, so it’s good to be prepared for the future.
The Inoreader team