-> OAuth 2.0 is the next evolution of OAuth protocol and is not compatible with OAuth 1.0.
-> OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones and living room devices.
The OAuth 2.0 specification defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs.
Actors in OAuth
There are four primary actors in OAuth:
Resource Owner (RO)
-> The entity that is in control of the data exposed by the API, typically an end user
-> The mobile app, web site, etc. that wants to access data on behalf of the Resource Owner
Authorization Server (AS)
-> The Security Token Service (STS) or, colloquially, the OAuth server that issues tokens
Resource Server (RS)
-> The service that exposes the data, i.e., the API
-> OAuth defines something called “scopes.” These are like permissions or delegated rights that the Resource Owner wishes the client to be able to do on their behalf. The client may request certain rights, but the user may only grant some of them or allow others that aren’t even requested. The rights that the client is requested are often shown in some sort of UI screen. Such a page may not be presented to the user, however. If the user has already granted the client such rights (e.g., in the EULA, employment contract, etc.), this page will be skipped.