If your business process needs a system whose resources can be accessed using OAuth authentication, you can use the OAuth system service to allow delegated access to private resources.
OAuth is an open protocol that allows secure API authorization in a simple and standard method. Users can grant third-party access to their resources without sharing their passwords and can also grant limited access, in scope or duration.
OAuth's method of delegated access to private resources uses two sets of credentials: the process consumer (in our case, a BPEL process) identifies itself using its identifier and secret, while the resource owner is identified by an access token and token secret. Each set can be thought of as a username-password pair (one for the application and one for the end-user).
Here are some examples:
A social network can pull a user's address book from their e-mail provider to make it easy for the user to invite friends to that social network
A photo printing service can pull a user's photos from their photo hosting service to print selected photos
A financial aggregation service can pull a user's financial details from their banks and credit cards companies to show a combined view of that information
The OAuth system service provides authentication, access token storage for future use, and a way to do communication with the provider post authentication.
The supported OAuth service providers are listed in the PDD, as shown.
As a prerequisite, for each provider you want to access, you must register with the service provider and obtain a client identifier key and secret. These parameters are required for the Partner Role configuration in the PDD.
The OAuth system service is a client-side component of the OAuth protocol, and it abstracts OAuth tokens and request tokens (which are elements of the OAuth protocol) by a user id. Each operation takes a userId as one of the input elements to identify existing tokens. A userId can have one authorized OAuth token per OAuth provider at any given time.