Forum Discussion

Jagruuti's avatar
4 years ago

Cannot perform OAuth 1.0 operation having the authorization variables in terms of String values.

Unable to generate the access tokens for OAuth 1.0 as ReadyAPI/SOAPUI does not have few fields which accept string values. Example: As shown in the attached word document file. 


Postman has fields which accept the values in string format whereas SOAPUI requires URL in some fields which restricts the user to perform API requests having OAuth 1.0 auth profile.


Thanks and Regards,


8 Replies

  • richie's avatar
    Community Hero
    Hey Jagruuti,

    I havent actually used the OAuth v1.0 config settings, but if a specific field in ReadyAPI! requires a URL then im guessing that these fields are defined in the rules as resolvable....i.e. you need these values from remote servers (im guessing its very similar to OAuth v2.0 which i have used before now)

    Just so youre aware, its a bit of a fallacy to compare Postman to ReadyAPI! for certain things and im guessing this is one of those things.
    As another example: the RFCs describing the different http methods/verbs that can be exercised in a REST request define a GET request as synonymous with an SQL SELECT request and doesnt include a payload. The RFC even suggests changing the method to POST if a payload is needed. ReadyAPI! doesnt by default support including a payload with a GET request (im guessing cos of what the RFC says), whereas Postman does support adding a payload to a GET request because the functionality in the tool isnt as tightly coded/constrained as ReadyAPI!

    N.b. Smartbear recently provided a config change that enables a payload field for a GET, but this is not the default config setting.

    I suggest you read up on OAuth functionality and the back and forth processing that occurs. This will allow you to understand/appreciate why certain fields are URLs.

    What im suggesting is that the ReadyAPI! functionality is actually working "as required" but youre misinterpreting how it should actually work.


    • Jagruuti's avatar

      Hi richie,


      I'm sorry if I have offended here anyone by comparing Postman with ReadyAPI.

      I have been initially using ReadyAPI in my project, but when I found that I was unable to create tokens for OAuth 1.0, I had to move to Postman.

      I also tried importing the request from Postman for OAuth 1.0, the request was not working. So I'm using 2 tools in my project- Ready API for OAuth 2.0 and Postman for OAuth 1.0. 

      I'm trying to automate everything in one tool. So I want this feature to be there in ReadyAPI. 


      Also, I would read the back and forth functionality why only URLs are required.

      But if my project comes up with this kind of requirements, then I think whichever tool I'm using should support all the requirements.

      This is the basic expectation that I have. After all, I have bought the license for it.






      • richie's avatar
        Community Hero

        Offend me? Youll have to try a lot harder than that fact, most people that know me would say im pretty much unoffendable!

        I appreciate that you want the tool to be able to exercise your requirements but if youre not using the tool in the method the RFCs and other supporting sources proscribe (when the tool has been coded to comply with those RFCs) then you can hardly blame the tool!

        The fact that youre developers have just given you strings to input to help you out, just doesnt work in this situation. The OAuth functionality is configured for your to obtain those values yourself...which is how id suggest most people would need the functionality to behave.

        I should highlight that you can still exercise apis using OAuth without using the OAuth functionality cos ive had to do this before myself (similar situation to project didnt provide me with what i needed) so i setup the individual REST calls of the back and forth processing of the OAuth myself.

        Just to be clear. Im not a Smartbear employee!

        Nice one,