What is OAuth 2.0?

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:

• Third-party applications generally store resource owner's credentials for future use, no guarrantees that they are storing sensitive information securelly i.e. passwords
• Servers are required to support password authentication, despite the security weaknesses created by passwords.
• Third-party applications generally gain total access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
• Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties, and must do so by changing their password.

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

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.

Using OAuth 2.0 to access a Resource

Web Services use the OAuth 2.0 protocol for authentication and authorization. SW Combine supports several OAuth 2.0 flows that cover common web server, JavaScript, device, and installed application scenarios.

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.