Valid Values for Components on the Platform

This topic includes lists of valid values for the following common elements used on the platform:

Element	Element
OAuth AttributeValueType	Sort By values
OAuth Client Type values
OAuth Grant Scope values
OAuth GrantStatus values
OAuth Grant Type values
OAuth Signature Method (1.0a) values
OpenID Connect Relying Party Response Mode values

OAuth AttributeValueType

OAuth AttributeValueType is a string data type, with valid values as follows:

string
number
boolean
nil
list
map

OAuth Client Type values

Valid values for OAuth Client Type are as follows:

Confidential: com.soa.oauth.ctype.confidential
Public: com.soa.oauth.clienttype.public

OAuth Grant Scope values

Valid values for OAuth grant scopes (for example, GrantScopeSetting in the OAuthProvider model object) are shown below.

Value	Description
provider_scope	The scope value to be used for a grant is processed as follows: If the authorization request/token request has a scope parameter and values (space-delimited string values), the authorization server validates whether the scopes are defined in the OAuth Provider. If they are, it uses the scope value as the grant scope. If the authorization/token request does not have a scope parameter, the authorization server takes the default scopes that are set in the OAuth Provider and uses them as the grant scope. If no default scopes are defined, the authorization server rejects the request and sends an error response.
client_default_scope	The scope value to be used for a grant is processed as follows: If the authorization request/token request has a scope parameter and values (space-delimited string values), the authorization server first validates whether the scopes are defined in the OAuth Provider. It then checks that the scopes are valid for the Oauth client. First it scans the APIs connected to the client, and then cumulatively collects all the OAuth scopes defined for these APIs. If the requested scopes are a subset of the app connection scopes, the request is valid and the request scope becomes the value of the grant scope. If the authorization/token request does not have a scope parameter, the authorization server scans the APIs connected to the client, and cumulatively all the OAuth scopes defined for these APIs are collected. These scopes are validated against the scope defined in the OAuth/OpenID Connect provider. If they are valid scopes, the request is valid. If they are not valid scopes, the authorization server rejects the request and sends an error message.

Value

Description

provider_scope

The scope value to be used for a grant is processed as follows:

If the authorization request/token request has a scope parameter and values (space-delimited string values), the authorization server validates whether the scopes are defined in the OAuth Provider. If they are, it uses the scope value as the grant scope.
If the authorization/token request does not have a scope parameter, the authorization server takes the default scopes that are set in the OAuth Provider and uses them as the grant scope. If no default scopes are defined, the authorization server rejects the request and sends an error response.

client_default_scope

The scope value to be used for a grant is processed as follows:

If the authorization request/token request has a scope parameter and values (space-delimited string values), the authorization server first validates whether the scopes are defined in the OAuth Provider. It then checks that the scopes are valid for the Oauth client. First it scans the APIs connected to the client, and then cumulatively collects all the OAuth scopes defined for these APIs. If the requested scopes are a subset of the app connection scopes, the request is valid and the request scope becomes the value of the grant scope.
If the authorization/token request does not have a scope parameter, the authorization server scans the APIs connected to the client, and cumulatively all the OAuth scopes defined for these APIs are collected. These scopes are validated against the scope defined in the OAuth/OpenID Connect provider. If they are valid scopes, the request is valid. If they are not valid scopes, the authorization server rejects the request and sends an error message.

OAuth GrantStatus values

Valid values for OAuth GrantStatus are shown in the table below.

Value	Alias	Meaning
Pending	OAuthGrantStatusPending	In a 3-legged OAuth flow, when an authorization request is requested by a client, once the request is validated a grant is created with a status of Pending.
Active	OAuthGrantStatusActive	In a 3-legged OAuth flow, during an authorization request, once the resource owner has been authenticated, the resource owner is presented with an authorization screen. When the user authorizes, or if authorization is automatic, the grant status moves from Pending to Active. In a 2-legged OAuth flow, the grant is created with a status of Active.
Rejected	OAuthGrantStatusDeclined	If the Resource Owner declines authorization of the grant, the grant status changes to Rejected.
Revoked	OAuthGrantStatusRevoked	If an active grant is revoked by the resource owner, the grant status changes to Revoked. A grant that is revoked can be reinstated, whereas a cancelled grant cannot.
Expired	OAuthGrantStatusExpired	By default, a grant is valid for 15 days. After the expiration timestamp, the grant status changes to Expired.
Cancelled	OAuthGrantStatusCancelled	If the Resource Owner, App Admin, or Provider Admin cancels the request, either at the Authentication or Authorization stage—before or after approval—the grant status changes to Cancelled. If a grant is cancelled, that is the end of the lifecycle.
ClientDeleted		The client deleted the grant.

OAuth Grant Type values

Valid supported values for OAuth GrantType (grant_type parameter) are shown below. These are per the OAuth 2.0 specification.

Standard OAuth grant types

Authorization Code grant: authorization_code
Implicit grant type: implicit
Client Credentials grant type: client_credentials
Resource Owner Credentials grant: password

Extension grant types

The platform currently supports the following extension grant type:

JWT Bearer grant: urn:ietf:params:oauth:grant-type:jwt-bearer

Refresh tokens

In scenarios where the client requests a new access token with a refresh token that was issued with an earlier access token, refresh_token is used as the value for the grant_type parameter.

A refresh token is not actually a grant type, but is used as the value for this parameter in this scenario, for grant types that support refresh tokens.

OAuth Signature Method (1.0a) values

The name of the signature method used to sign an OAuth 1.0a request. Valid supported values for the OAuth 1.0a oauth_signature_method parameter are as follows:

PLAINTEXT
HMAC-SHA1
HMAC-SHA-1
HmacSHA1
HMAC-SHA-256
SHA-256
HMACSHA256
RSA-SHA1
SHA1withRSA
RSA-SHA256
SHA256withRSA

OpenID Connect Relying Party Response Mode values

The response_mode value in the request determines the type of response that will be returned. Supported values for the platform's OpenID Connect Relying Party domain response mode (response_mode parameter) are as follows:

form_post
query
fragment

Sort By values

As part of retrieving some types of information, such as the Board for an app or API, you can define a sort value for the information that's returned. Valid values are shown below.

This sort by...	Has this value...	Which indicates this Selection...
SORT_BY_UPDATED	com.soa.sort.order.updated	Most recently updated items are first.
SORT_BY_RELEVANCE	com.soa.sort.order.relevance	Items with the highest relevance are first.
SORT_BY_ALPHABETICAL	com.soa.sort.order.alphabetical	Sort alphabetically (A to Z, with A at the top).
SORT_BY_RATING	com.soa.sort.order.rating	Sort with the highest ratings at the top.
SORT_BY_CONNECTIONS	com.soa.sort.order.connections	Items with the most connections are first.
SORT_BY_FOLLOWERS	com.soa.sort.order.followers	Items with the most followers are first.