The following section briefly describes the concepts and workflow of the OAuth authentication process.
Tip: For more details about OAuth, refer to RFC 5849.
The OAuth process involves the following three entities:
The diagram above shows the following:
The double-headed arrow between the User and Consumer shows that a request and response is made between the two.
The double-headed arrow between the Consumer and the Service Provider shows that a request and response takes place between the two.
The arrow at the bottom shows that, after the OAuth process, the User is able to access resources from the Service Provider.
|OAuth RoleA grouping of user permissions, which, when assigned to a user, defines the tasks that they can perform on behalf of their accounts.||Description||OpenX Implementation|
|Service Provider||A web application that allows access via OAuth.||OpenX|
|Consumer||A website or application that uses OAuth to access the Service Provider on behalf of the User.||Your client application|
|User||An individual who has an account with the Service Provider.||Users of your client application|
OAuth defines three request URLs:
|URL Type||Description||OpenX Implementation|
|Request Token URL||Used to obtain an unauthorized Request Token||https://sso.openx.com/api/index/initiate|
|User Authorization URL||Used to obtain User authorization for Consumer access||Browser-based: https://sso.openx.com/login/login Programmatic: https://sso.openx.com/login/process|
|Access Token URL||Used to exchange the User-authorized Request Token for an Access Token||https://sso.openx.com/api/index/token|
For a complete list of parameters, see the OAuth specification. There are a few parameters worth mentioning:
|Oauth_nonce||This parameter contains a nonce or "only once string"; it is a unique string that changes on each OAuth request. There is no specification on how the nonce should be constructed, but it is important to make sure it changes on each call; it is how the server knows there are no duplicate requests.|
|oauth_token||This value changes based on the stage of the OAuth handshake. Before authorization and when getting a request token, this parameter is excluded entirely. When retrieving an access token, this parameter is set to the request token. Once an access token has been obtained, this parameter, for all future requests, is set to the access token.|
|UNIX timestamp||The oauth_timestamp field requires a UNIX timestamp. Some programming libraries may provide a function for this.|
The following graphic illustrates the flow of information in the OAuth process. It takes place is basically three steps:
The Consumer obtains an unauthorized Request Token (Steps 1.1 and 1.2)
The User authorized the Request Token (Steps 2.1, 2.2, and 2.3)
The Consumer exchanges the Request Token for an Access Token (Steps 3.1 and 3.2)
The numbered steps in the graphic correspond to the numbered steps in this section.
Solid arrow - Person using web browser/Manual entry
Dotted arrow - Consumer/Service Provider