Skip to Content
Technical Articles

OAuth 2.0 Standard Solution with Grant Type as Password in SAP PO 7.5(with Latest Updates)

This blog portrays the OAuth2.0 authorization with grant type as ‘Password’.This is implemented in SAP PO 7.5 SPS 16 Patch 15. Lets take a tour into the Standard solution in elucidate with latest updates. 🙂 Over to content below:

1. Introduction:

 OAuth(Open Authorization) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

   OAuth introduces an authorization layer separating the role of the client from that of the resource owner.In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service: 

(i) On behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service  (or)

(ii) by allowing the third-party application to obtain access on its own behalf.

2. Purpose:

 The purpose of this blog is to explain OAuth 2.0 in SAP PO 7.5 SPS 16 with grant type as password.Regards to OAuth 2.0 solution worked with SAP in testing this solution and identifying bugs which resulted in correction notes published in the SAP marketplace to make this solution more robust to solve different OAuth 2.0 authentication integrations with varied systems/applications.

3. Authorization Code Grant flow:

 Below diagram depicts the Authorization Grant Flow to retrieve the access token and refresh token, POST a call to the authorization server. The client requests authorization from the resource owner and receives grant and then requests tokens by authenticating with the authorization server and presenting the grant. Authorization server validates, if valid then issues the initial access token and initial refresh token with access token expiry(lifetime in secs). 

Below diagram elucidate that the client requests the protected resources from the resource server and authenticates by presenting the access token. The resource server validates the access token, and if valid, serves the requests and retrieves the response from the protected resources.

4. SAP PO REST Adapter Configurations:

Before proceeding with the REST receiver communication channel configurations below is the Authorization server (which grants tokens) HTTP request header and HTTP request Body parameters look alike 😉

HTTP Request Headers:

HTTP Request Body:

HTTP Response Body:

Below is the Resource server(which does the actual business call) HTTP request header and HTTP request Body parameters look alike

HTTP Request Headers:

HTTP Request Body:

 In the REST receiver communication channel that allows you to configure with OAuth 2.0 Client Credentials Grant and Resource Owner Password Credentials Grant. Below configurations explains only about the resource owner password credential grant type.

To Configure the REST receiver channel following are the steps below:

   1. To enable new OAuth 2.0 Grant flows, in the “General” tab, check “Authorize with OAuth” checkbox and select “OAuth 2.0 Grant Type Flow”.You can choose from the following grant flows:

   2. You can configure how to use the received access token as defined in https://tools.ietf.org/html/rfc6750.

Select following values for the field “Use credentials and OAuth 2.0 access token as” :

  • HTTP Header – adds the access token to the request HTTP headers in the following format “Authorization: Bearer <access_token>”
  • Query Parameter – adds the access token to the resource URL in the following format: http://<host>:<port>/<resource_path>?access_token=<access_token_value>
  • Important Note: This OAuth2.0 functionality extracts only the access token and not the refresh token.
  • Sending access token as “Form-Encoded Body Parameter” is not supported.

3. You can configure the following parameters for OAuth 2.0 Grant Type flows:

For Client Credentials Grant:

For Resource Owner Password Credentials Grant :

4. OAuth 2.0 Additional parameters need to maintained for the remaining HTTP header and HTTP Query parameters. You can specify the “Parameter Type” to be one of the following:

  • Query –  Parameter will be added to the URL query(HTTP Body).
  • HttpHeaderParameter will be added as HTTP Header.
  • Important Note: As per SAP note 2721684 and 2782239 ,which denotes that in order to send OAuth 2.0 additional  HTTP header parameter; with the request.Patch needs to be applied which matches the respective Support Package version(as per SAP Note 952402).It works only with >SAP PO 7.5 SPS 15 Patch 0001. With out any patch upgrade below is the error:

Error while obtaining authorization code – response code: 400 response:

{“errorCode”: “GTW-ERROR-001″,”message”: “appkey not found in Header or it’s not correct.”}

5. In the REST URL, provide the resource server URL which does the actual business API call.

6. Below is the HTTP headers of the resource server:

In the HTTP Headers, there is no necessity to enforce Authorization: Bearer <access_token>.It will be added since in ‘General tab’ it is defined use access token as HTTP header.

appkey‘ is a valid application key passed in HTTP Header which allows you to track your API usage per application.’Content-Type‘ is the type of representation desired at resource side.

5. Additional Feature- Resource Owner Password Credentials Grant:

When partner server does not support Authorization Basic HTTP Header which got added as Authorization: Basic <credentials> since the authorization user name and password is configured in Communication Channel. There is no configuration which is used to exclude this header before and same is raised with SAP for the additional feature.

As per OAuth2.0 standard Authentication framework, the client must not use more than one authentication method in each request.Refer: https://tools.ietf.org/html/rfc6749#section-2.3

Solution from SAP:  New module parameter is defined to the REST receiver channel that allows you to specify how the user authentication is requested from the partner authorization server.Refer SAP Note 2878625.

Parameter name Parameter value Perform
Oauth20AutorizationServerRequestType

header

(default)

Use the default value header and the fields Authorization Server Username and Authorization Server Password will be used for creation Basic Authorization HTTP Header
query

Use value query and the fields Authorization Server Username and Authorization Server Password will be used for client_id and client_secret in the OAuth query string.

Note:When you use value query do not use field Resource Owner Client ID. This will cause the client_id twice in the query string.

none Use value none and the fields Authorization Server Username and Authorization Server Password will be ignored and no Basic Authorization HTTP Header will be sent (Additional feature requested to SAP)

Note: When you use a value query do not use the field Resource Owner Client ID. This will cause the client_id twice in the query string.

Result: Now using the above Parameter name as ‘’Oauth20AutorizationServerRequestType’ and Parameter value as ‘none’ in the module configuration. Basic Authentication is now ignored from the HTTP header and dispatched as part of the HTTP body only as ‘username’ and ‘password’ appropriately to get the access_token.

Important Note: As per SAP note 2878625 which denotes that in order to send OAuth 2.0 additional query or header parameter; with the request.Patch needs to be applied which matches the respective Support Package version(as per SAP Note 952402).It works only with >SAP PO 7.5 SPS 16 Patch 000014. With out patch upgrade below is the error:

Error while obtaining authorization code – response code: 400 response:

{“error_description”: “Client authentication failed”,”error”: “invalid_request”}

6. OAuth Token Caching:

PI REST receiver channel with configure OAuth 2.0 Authentication and grants type flow allows the generated Token to be reused depending on the value of the ‘expires_in‘ parameter.

The access token is usable from the moment it is generated until the number of seconds defined by expire_in elapses.

‘Expires_in’ parameter is described in https://tools.ietf.org/html/rfc6749#section-4.2.2

To enable the OAuth 2.0 Token Caching, in the “General” tab, under “OAuth” section, check the new “Use OAuth Token Caching” checkbox*.

* Please, note that this checkbox is enabled by default.

Token caching behavior with respect to server node and parallel call as per SAP implementation and reply from technical team,

  1. Token Caching is implemented completely in-memory without any persistence, thus the fact that on each server node there will be separate cache instance. When the token is expired on the first call will remove it from cache. 
  2. Latest token value is  to be stored, thus the expiration time will be the maximum offset in the future.  There is no problem update or removal expired token when there is parallel calls to the adapter to use existing tokens or update new token.

Access token is extracted and added to ‘OAuth20TokenCache’ with

Key: authorizationUrl_client_id

Value: *access_token* expiresIn: 2020-01-31T09:18:09.542 (yyyy-MM-ddTHH:mm:ss.SSS).

 This expiry is based upon the field “expires_in” from the HTTP response json payload.

  Say 1799 seconds it exactly calls a new token. Token is searched in ‘OAuth20Token’ Cache and uses the access token for the next consecutive and Concurrent calls till its expiry.After the access Token expiry,  Authentication API is immediately called and retrieves a fresh access token and update in Cache(OAuth20Token).Access Token expire exactly after 30 minutes and the expiry timestamp format used is ‘yyyy-MM-ddTHH:mm:ss.SSS’.

7. Troubleshooting:

1. Goto PI Message monitoring, check for the message logs.’Authorization’ will not be visible in audit logs and secured.

2. Goto to NWA log viewer for a detailed debug traces.

3. Enable XPI inspector log with corresponding REST adapter channel and check the HTTP client log, we can see the HTTP request header, body of adapter configuration and response header and body message Authorization server.

Note: Please Ensure SPS or Patch upgrade are applied on Sandbox environment and smoke tested thoroughly and then implemented in other environments.

 

Happy Reading!🙂

37 Comments
You must be Logged on to comment or reply to a post.
  • Hi Rajesh,

     

    A good one , finally much needed solution has come out in PO in order to deal with OAUTH  requirements.

    Thanks for the updates:)

     

    Regards,

    Bhaskar.

  • Hi Rajesh

    Thank you for the detailed blog. I have been trying a lot lately to get my Oauth authorization working with no luck. I keep getting below error:

    HttpCallException: HTTP OAUTH 2.0 RESOURCE OWNER PASSWORD CREDENTIALS GRANT call to https: <url> <port> /auth/oauth/token not successful. Error while processing Authorization request

    response:
    {“error”:”unauthorized”,”error_description”:”Full authentication is required to access this resource”}

    Could you please have a look and suggest if I am missing something? Looking at the error I have the feeling that not all the parameters are getting passed along with the request. Thank you in advance.

    /
    • Error clearly states that it  is not holding full permissions to access the resource.
      Please check with the resource owner on the User credentials.I faced same issue and then I used the user credentials provided by them for specific resources.

      Before checking generate access token in postman and execute the resource with that generated access token in POSTMAN .

      {“error”:”unauthorized”,”error_description”:”Full authentication is required to access this resource”}

  • Thank you for your response.

    I have below details given by the Resource owner and I am able to receive the token correctly from POSTMAN:

    Method: POST
    Url: https:// <url>: <port> /auth/oauth/token
    – Headers:
    Content-Type: application/x-www-form-urlencoded
    Authorization: <authorization>
    – Body (x-www-form-urlencoded):
    username: <username>
    password: <password>
    grant_type: password
    Response content-type: application/json

    So I would like to know where exactly in the configuration I can put all the above parameters, specially the ones for Body – Authorization, grant_type etc. I have tried them under Oauth 2.0 Additional Parameters as HttpHeader and Query both and seem to have no effect.

    • Configurations seems to be incorrect. Please read the blog patiently and follow it carefully. For example (from your snapshot) additional parameters i.e. grant type, authorization aren’t required.

      • I am aware that grant_type is not needed when you choose the option RESOURCE OWNER PASSWORD CREDENTIALS, and Authorization here is not the bearer one, this one is a mandatory parameter with value “Basic ZWJpdGNsaWVudDpzM2NyM3Q=” to fetch the token without which it does not work even in POSTMAN. Username and password are already mentioned.

        I have tried with and without the additional parameters with the same result. I am out of options with the Rest adapter configuration. Do I have to send the body parameters in message mapping?

         

        • I am able to reproduce the issue in postman.

          XPI inspector logs revealed that the request is not using my Authorization value, instead it is generating and sending its own value. If I use the generated value as Authorization and send request via postman, I am getting the exact same error. Rest of the parameters are fine. 

          I already tried setting Oauth20AutorizationServerRequestType to none but it still sends the Basic Authorization key.

          • Dear Shukla,

            have you been able to solve this issue?
            Facing the same problem and it seems he also shows different values in XPI inspector.

            We are facing this issue since an upgrade.

            Thanks
            Chris

  • Hi Rajesh,

    Current configuration uses Authentication: token in 3rd party REST adapter to retrieve access token from Ariba API.

    I am trying to achieve same functionality using Standard REST adapter and have the below queries.

    1. Token endpoint and Authorization URL are one and the same ?
    2. I have selected OAuth 2.0 Grants type flow – Client Credentials grant to get access token.
      But in standard rest, how do we differentiate and identify between token HTTP request, token HTTP response and actual data HTTP request headers in channel configuration.

      Custom Request HTTP headers (3rd party REST adapter) inputted in Additional HTTP Headers section( standard REST)

      and token HTTP Request headers(3rd party REST adapter) inputted in OAuth 2.0 Additional parameters(standard REST).

    Kindly let me know your thoughts or suggestions on the approach.

    • Hi ramya mareedu

      Kindly find my comments in flower brackets.

      1. Token endpoint and Authorization URL are one and the same ?  {Yes,it is the Authorization server URL under General Tab Oauthorize with Oauth}.
      2. I have selected OAuth 2.0 Grants type flow – Client Credentials grant to get access token.
        But in standard rest, how do we differentiate and identify between token HTTP request, token HTTP response and actual data HTTP request headers in channel configuration.Custom Request HTTP headers (3rd party REST adapter) inputted in Additional HTTP Headers section( standard REST) –{could you elucidate this}
  • Hello Rajesh,

    I am trying to use the below.

    Grant Type: Resource Owner Password Credentials Grant

    Token as: HTTP Header

    Authorization Server URL: https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token where tenantid is provided as part of Open ID Connect details

    Resource Owner Client ID: Application (client) ID provided  as part of Open ID Connect details

    Auth Server User/Password and Resource User/Password – I am using my Microsoft credentials.

    The error I am getting is HTTP OAUTH 2.0 RESOURCE OWNER PASSWORD CREDENTIALS GRANT call to https://login.microsoftonline.com:443/<tenantid>/oauth2/v2.0/token not successful. Error while processing Authorization request.

    Any ideas will be helpful.

    Thanks,

    Shaibayan

  • Hi Rajesh,

    I have requirement as below, I am using SAP PO 7.5 SP Stack Number 16.

    1. oAuth Service has to be called by a post without body payload using below parameters. client_id and client_secret are not base64 encoded.

    Method: POST
    Url: https:// <url>/oauth2/v2.0/token
    – Headers:
    Content-Type: application/x-www-form-urlencoded

    – Body (x-www-form-urlencoded):
    scope:
    client_secret:
    client_id:
    grant_type:client_credentials

    Request%20from%20Postman

    Request from Postman

    OAUTH%20settings

    OAUTH settings

    ***************************************
    Response:
    “token_type”: “Bearer”,
    “expires_in”:
    “ext_expires_in”:
    “access_token”:< token value>

    Sample%20Token%20Response%20from%20Postman%20tool

    Sample Token Response from Postman tool

    2. Once Token is retrieved, I need to pass it in http header values in the real API REST Adapter as below
    content-type: application/json
    Authorization: Bearer < token value>

    HTTP%20Header%20parameters

    HTTP Header parameters

    Ping%20channel%20-%20401%20Unauthorized%20error

    Ping channel – 401 Unauthorized error

     

    please advise  if above settings are correct and can it be achieved in single interface ?

     

    Thanks,
    Varun

    • Hi Varun K

      Looks good to me. But don’t enforce the client id, client secret and as well authorization again in Oauth additional parameters. You can discard those three parameters from additional.Also cross check the module parameter and specify it appropriately(header,query,none).

      Note: Client credentials should be secured since its a sensitive information and anyways SAP will add the client secret field to the adapter UI element and mask it.SAP release this in SP20 with targeted delivery is Q1/2021(Just an Update).

  • Good to know that the client secret must be encoded if it contains special characters. This was the issue for my error i received:

    Error while obtaining access token – response code: 400
    response:
    {“error”:”invalid_client”}

  • Hi all,

    I’m trying to consume an API provided by an MS Azure service. I am using https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token with “client credentials” grant type.

    • All works well in Postman
    • However, in PI I get “HTTP OAUTH 2.0 CLIENT CREDENTIALS GRANT call to https://login.microsoftonline.com:443/<tenant>/oauth2/v2.0/token not successful. Error while obtaining access token – response code: 401
      response:
      {“error”:”invalid_client”,”error_description”:”AADSTS7000216: ‘client_assertion’, ‘client_secret’ or ‘request’ is required for the ‘client_credentials’ grant type” […]}
    • I’m on PI AEX 7.5 SP13.
    • I have not introduced any module parameters since I think the microsoft service will not support query parameters

    Do I need to patch my system for this to work?

    Has anybody successfully set up a oAuth authentication to MS Loging Service?

    Cheers

    Jens

  • Hi,

     

    Do you have experience with ‘JSON Web Token Credentials Grant’?

    For a client, there is a requirement to implement JSON web token but they only accept grant_type ‘client_credentials’. When we use JSON web token credentials grant in the PI channel, it will send grant_type ‘JWTCredentialsGrant’.

    Is there a possibility to override the grant type or is it only possible with 2 iFlows (authentication and API call) ?

     

    Thanks!

    Tom

  • Hi Rajesh,

    Thank you so much for this helpful step by step. I need to configure OAuth for IMAP4 Mail Sender.

    But not sure what is wrong with my Mail adapter. I can’t see the checkbox for “Configure OAuth Authentication” after implemented 2928726 – NewF: Support for OAuth 2.0 in PI Mail adapter. Can’t see any OAuth in my mail adapter metadata as well.

    Need your valuable advise. Thank you.

    Cheers,

    Maxine

     

    • Hi,

      We got the missing fields after downloading the latest Basis software component *.sca

      • Note 1536986 – How to import PI Content into the ESR.

      Cheers,

      Maxine

        • Hi Rajesh,

          I am so happy to receiving your response.

          Wasn’t able to see the checkbox for OAuth before this, we are using Mail adapter with OAuth, no Grant type. 🙂 Thank you so much Rajesh PS, OAuth part is working now.

          OAuth%20with%20mail%20adapter

          OAuth with mail adapter

           

          Cheers,

          Maxine

          /
          OAuth%20with%20mail%20adapter
          • Hey marcos mendes,

            Thanks 🙂 

            I see the grant type is ‘client credentials’ only the below parameters will be present in the HTTP body while requesting for an access token. Authorization scope is limited to the protected resources under the control of the client and doesn’t require user’s permission.

            Body

            • grant_type with the value client_credentials
            • client_id with the the client’s ID
            • client_secret with the client’s secret
            • scope with a space-delimited list of requested scope permissions(optional).

            Header:

            • application key(optional)
            • content type

            In your screenshot, under Oauth additional parameters you can discard the entry ‘Authorization’. Just cross verify the REST configurations and compare with POSTMAN collection once.

             

            I had tested this client credentials grant type earlier in SAP P0 7.5 SP16 faced below error.

             

            HTTP OAUTH 2.0 CLIENT CREDENTIALS GRANT call to https://host:443/api/authentication/access_token not successful. Error while obtaining access token – response code: 401
            response:
            {“error_description”:”Invalid authentication method for accessing this endpoint.”,”error”:”invalid_client”}

            Probably eyeball this with XPI Inspector HTTP traces in detail.

            Nothing additional parameters to be configured as I had already mentioned above the HTTP header and body and its straightforward config and nothing additional to be incorporated.

            Cheers,

            Rajesh PS

            /
            🙂
  • hey Rajesh,

     

    Yes, i guess will need to do it.

    i’m still getting the same error “401”.

    if you have any ideas, will appreciate.

     

    Marcos Mendes

    /
  • Hi Rajesh,

    I have requirement as below, I am using SAP PO 7.5 SP I am using File –> PI –> REST API to get the token.

    I am sending the granttype in am xml file from file server to REST call for getting token as Oauth 2.0 Grants type flow feature is not available.

    1. oAuth Service has to be called by a post Url: https:// <url>/oauth2/v2.0/token

    Body:

    grant_type : openapi_2lo

    Body

    Body

    Headers:

    postman%20Header

    postman Header

    My channel config.details are below. Please suggest me how to include content_type: multipart/form-data; boundary=<calculated when request is sent>  in the http header parameters.

    Kindly suggest me if my configurations are correct and what is the cause for this error.

    marcos mendes  could you please share your CC confg. changes you did to resolve this issue?

    Appreciate your valuable advice!

    Thanks,