OAuth: Prerequisites to using OAuth2

Discuss this help topic in SecureBlackbox Forum

The OAuth protocol has been designed to authenticate users of online projects through the third-party authorization servers, eliminating the need to create multiple online accounts. This way, a single account, e.g., Google or Facebook, allows to access various services such as mail, calendar, etc. Note, that the OAuth 2.0 protocol (RFC 6749) shares very few implementation details with the OAuth 1.0 protocol (RFC 5849).

To use OAuth in desktop applications you would need:

an HTTPS client to establish an OAuth session with the authorization server;
a web browser with JavaScript support which will be used to authenticate the end-user (resource owner) with the authorization server;
a local HTTP server to receive the authorization codes.

Before using OAuth the application (client) should be registered on the authorization server. It usually requires the application name, shown to end-user (resource owner) during authentication, and the URL to which the authorization server should send the authorization code (access token). The web browser running on the end-user's side is redirected to that URL after successful authentication. For desktop applications, the redirection URL can be specified as http://localhost:<port>/ . Some authorization servers allow not to specify the port number when registering the application in their console. They determine it dynamically depending on what ports are available on user's computer, before initiating the authentication session. Some servers allow not to register localhost as a redirection URL, i.e., such redirection is always allowed.

The following information is required by the authorization server to grant access to the protected resource:

A URL of the authentication page which will be shown to the user in the browser.
A URL where access tokens (authorization codes) are sent upon successful authentication. For Google this URL is https://accounts.google.com/o/oauth2/token.
Client ID and Client Secret identifiers of the application, previously registered with the authorization server.
A URL to which the authorization server will redirect user's web browser upon authentication, and where the application will wait for the authorization code. Some authorization servers have a special operation mode, which allows not to specify this redirect URL. Instead, they show a specific page to the user, where authorization code is shown. This code could be copy-pasted to the application that needs it. Such operation mode makes it unnecessary to run the dedicated local HTTP server for receiving authorization codes.
Some servers require that each client (application which needs access to the protected resource) provides the list of resources (objects or operations) it is going to use. These are so-called "scopes". Scopes are text identifiers which are usually described in the server's documentation. For example, to get user information on Google servers you need to specify the following scopes: https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile. Scopes can be composed of almost any text, not just URLs.

How To articles about client-side OAuth questions

Discuss this help topic in SecureBlackbox Forum