A. When your application needs to authenticate the member (aka the "user"), your application makes a call to LinkedIn to ask for a request token

B. LinkedIn replies with a request token. Request tokens are used to ask for user approval to the API.

C. Your application redirects the member to LinkedIn to sign-in and authorize your application to make API calls on their behalf. You provide us with a URL where we should send them afterward (aka the "callback")

D. If the member agrees, LinkedIn returns them to the location specified in the callback

E. Your application then makes another OAuth call to LinkedIn to retrieve an access token for the member

F. LinkedIn returns an access token, which has two parts: the oauth_token and oauth_token_secret.

G. After retrieving the access token, you can make API calls, signing them with the consumer key and access token

More information about the OAuth flow can be found on the OAuth standards site at http://www.oauth.org

OAuth is a security protocol designed to allow delegated API Access. It is available on the Elgg platform through the OAuth Plugin. This page is meant to document usage of the OAuth plugin from within Elgg, not to explain the use of the OAuth protocol itself.

Library

The OAuth Plugin is a library that allows an Elgg installation to act as a client or a server in an OAuth-protected mechanism. User-facing access to the plugin is available through the "Applications" link on the tools menu.

The OAuth Plugin supports both version 1.0 and revision 1.0a of the OAuth protocol. Consumers must be flagged as supporting 1.0a at creation time, either by checking the "1.0a" checkbox upon registration or by passing a flag to the oauth_create_consumer function call.

Outbound

The outbound (client) functionality allows an Elgg site to connect outward to another OAuth-protected site or resource. The OAuth plugin will manage all necessary tokens and consumers as Entity objects in the database. The plugin also provides views and actions for requesting tokens from a far side site.

Note that the code mentioned here is meant to go into your own plugin's space and not in the OAuth plugin itself!

[...]

Inbound

The inbound (server) functionality allows other software to access an Elgg instance using OAuth as the authentication mechanism. This works by allowing users to register consumer applications on the site and using those consumers to get request and access tokens. The validated access tokens can then be used as an authentication key (using the standard OAuth protocol) to access any URL on the site, though it makes the most sense for the Elgg API.

This library could act as the basis for connecting Elgg sites together in a secure manner, allowing for mobile profiles and smart access to protected Elgg resources between sites, but it does not do that directly itself.