Inbound REST Requests and OAuth Scopes

The Siebel application will honor the OAuth scope (the types of APIs you may call and operations you may perform for incoming REST requests) that you supply and that you have defined in your OAuth server. When you get your OAuth token, it will define the scope you have defined and pass that to the Siebel application. You can define the scope of your operation from general to specific. If you are using a scope of GET, for example, you would use the same token you got from your Oauth server for any GET request. If you have refined the scope further by adding the data API for GET operations, then you use your Oauth token for all GET data operations. As shown below, you can define your scope to gradually become more restrictive. When the incoming REST request is read, the Siebel application verifies the scope for the operations provided with your OAuth token, with the actual request to make sure that the REST request it has received is authorized to perform the operations it is requesting.

These are simple examples of scopes you may have defined in your OAuth server:

Note: This example shows the data API, but this is true for all other Siebel CRM REST APIs such as service, workflow and others. These examples show a single API, but you can pass more than one API as scope by separating them with a space.

Scope: “data service workflow” sends three APIs. You can refine each one individually such as:

Scope: data.Account.Account workflow.<workflowname>

Here the scope is that we are calling the GET method for the data resource. This scope allows the REST request to get data from any resource and is wide open.

GET.data

Now the REST request is limited to getting data from the Account resource. Account is the Business Object and has many possible child Business Components. This allows getting data from any of those children.

GET.data.Account

This is the final stage where we are restricting reading data from only the Account Business Component as a child of the Account Business Object.

GET.data.Account.Account

The same can be done for the other types of HTTP methods such as POST, PUT, DELETE.

This restricts updates to only the Account BC under the Account BO.

POST.data.Account.Account

This restricts inserting records to only the Account BC under the Account BO.

PUT.data.Account.Account

This restricts deleting records to only the Account BC under the Account BO.

DELETE.data.Account.Account