Skip to Content

SAP Jam Per-User Authentication at SAP Gateway

The SAP Jam Developer Guide describes how you can register an external application. One prominent example is the consumption of OData services via SAP Gateway. The remainder of the document provides more details on how to activate per-user authentication of SAP Jam at SAP Gateway.

The authentication of Jam at SAP Gateway is based on the OAuth2 server of SAP NetWeaver ABAP.
Official documentation:


Be sure that the following notes are applied to your Gateway system:

  • 2008737 - Too many OAuth 2.0 applicable ICF handlers registered
  • 2083419 - OAuth 2.0 Server: Grant type SAML 2.0 Bearer Assertion - Problem with NameFormat email & NameID Management
  • 2094134 - Too many OAuth 2.0 applicable ICF handlers registered.

Step#1: OData Service enablement:

It is  described in the given application documentation (e.g. CRM: notes 1891369 & 1928182) which OData services need to be maintained at the SAP Gateway system.
In addition you need to run report /IWFND/R_OAUTH_SCOPES in order to generate the OAuth2 scopes for these services. Reference:

The Service Doc. Identifiers follow the pattern:  <Technical Service name>_<Service Version>, example: Z_SAIL_CRMSMI_SRV_0001.The generated scope corresponds to the service document identifier. This is the value that needs to be entered at the external application in Jam later on.

The DB table comprising the scopes is OA2_SD_SC.


  • In transaction /IWFND/MAINT_SERVICE there is an indicator that shows if the scopes have been generated or not.
  • After the OAuth2 enablement, the regular ICF event handler class for OData services, /IWFND/CL_SODATA_HTTP_HANDLER, should have been replaced by an inheriting class /IWFND/CL_SODATA_HTTP_HNDL_OAT.
    Verify this by navigating to the ICF node (ICF Node -> Configure (SICF) from transaction /IWFND/MAINT_SERVICE).

Step#2: Trust Relationship to the Security Token Service (STS)

Register SAP Jam at transaction SAML2 as described in the following references:

Hereby the general pattern for the  OAuth 2.0 Identify Provider is: https://<proxy of you data center>/sf/oauth2/company/<your company name>.

  1. Identity federation: E-mail
  2. Signature and Encryption: here you have to manually insert the primary signing certificate.

Someone with provisioning access (i.e. a person in Customer Support) needs to get the certificate. This is obtained as follows:

Note there is another link to "Reset Certificate". If you click this link SFSF Platform prompts you to confirm with "This operation is irreversible. You will have to reconfigure integrated application with the new certificate. Do you want to continue ?" If you continue, it generates a new certificate.In particular, these certificates are specific to a given company, and are not shared between test and production companies. They are even subject to change for a specific company via this "reset certificate".

Step#3: OAuth 2.0 Client Registration

Proceed as described in the following references:

Please follow the naming convention for the service user at SU01: JAM_OAUTH. Make sure the service user is a SYSTEM user on SAP Gateway and the password matches the secret field on Jam (step 6, per-user authentication).

At transaction SOAUTH2, the same value JAM_OAUTH can be used as the OAUTH2.0 Client ID. Description: Jam OAuth.
The same OAuth 2.0 client ID must be used when registering the external application in SAP Jam later on.

Grant Type SAML 2.0 Bearer must be active.
Client User ID & Password must be active  (as the first authentication takes place with the JAM_OAUTH user and basic authentication).
SSL Client Certificate must also be active.

Trusted OAuth 2.0 IDP: enter the IdP registered at step#2 (https://<proxy of you data center>/sf/oauth2/company/<your company name>) with Identity Federation = E-mail
Scope assignment: add the scope ID = service document identifier from step 1, e.g. Z_SAIL_CRMSMI_SRV_0001. Add the scope for each backend service (= business record type) that needs to be addressed.

Step#4: Configure OAuth 2.0 to use a SAML 2.0 bearer grant type

Follow the instructions at

Step#5: Resource Owner Authorizations

Each end-user has to have the Authorization (object) S_SCOPE at the Gateway server, with the value of each service the user shall be able to access. It is not recommended to use the value ‘*’ and thus enable all services. Establish a new role comprising the following field values for authorization object S_SCOPE
OAuth 2.0 Client ID            Enter the OAuth client ID from step #3
OAuth 2.0 Scope ID           Enter each scope the you have generated in step #1

Step#6: Continue with the SAP Jam Developer Guide
Establish the per-user authentication for your external application

The OAuth 2.0 client ID must have the same  value as registered in step #3


  1. First try if the connection works with common user authentication. Note: Before doing  this please note the values you have entered for the per user authentication.
  2. On the SAP Gateway server, you can start an authorization trace with report SEC_AUTH_TRACE
  3. You can also start the ICF recording at transaction SICF
  4. Check note 1688545 for additional hints on troubleshooting OAuth 2.0

No comments