In the traditional client-server authentication model, the client accesses a protected resource on the server by authenticating using the resource owner's (i.e. user) credentials. In order to provide third-party applications access to protected resources, the resource owner shares its credentials with the third-party. This creates several problems and limitations:
OAuth addresses these issues by introducing an authorisation layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token that denotes specific scope, duration and other access attributes. Access tokens are issues to third-party clients by an authorisation server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
Authorisation is act of verifying that the requester should have access to what they want.
As mentioned previously OAuth provides an abstraction layer via access tokens, replacing different authorisation methods with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the resource owners credentials used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
OAuth 2.0 is a relatively simple protocol and a developer can integrate with the OAuth 2.0 endpoints without too much effort. In a nutshell, you register your application with SW Combine, redirect a browser to a URL, parse a token from the response, and send the token to the Web Service you wish to access.
For an overview of the OAuth 2.0 scenarios supported, see Using OAuth 2.0 to access a Resource.