OAuth 2.0 Postman Pre-Request Issue

Authorization using the same set of creds being set in the environment works when auth is being done through Postman interface but not with the pre-request script.

Using this through Postman interface and it works:


But fails when used through the following script:

const accessTokenUrl = pm.environment.get("access_token_url");
const clientId = pm.environment.get("client_id");
const clientSecret = pm.environment.get("client_secret");
const scope = pm.environment.get("scope");

if (accessTokenUrl && clientId && clientSecret) {
    const getTokenRequest = {
        url: accessTokenUrl,
        method: 'POST',
        header: {
            'Content-Type': 'application/x-www-form-urlencoded'
        },
        body: {
            mode: 'urlencoded',
            urlencoded: [
                { key: 'grant_type', value: 'client_credentials', disabled: false },
                { key: 'client_id', value: clientId, disabled: false },
                { key: 'client_secret', value: clientSecret, disabled: false },
                { key: 'scope', value: scope, disabled: false }
            ]
        }
    };

    pm.sendRequest(getTokenRequest, (err, res) => {
        if (err) {
            console.log('Token request error:', err);
        } else {
            const jsonResponse = res.json();
            if (jsonResponse.access_token) {
                pm.environment.set("access_token", jsonResponse.access_token);
                pm.request.headers.add({
                    key: 'Authorization',
                    value: `Bearer ${jsonResponse.access_token}`
                });
            } else {
                console.log('Token request failed:', jsonResponse);
            }
        }
    });
} else {
    console.log("Missing environment variables for token request.");
}

For this, I even did this step:

  1. Authorization Header:
  • Go to the request where you need to set the authorization header.
  • In the Authorization tab, select Bearer Token.
  • In the Token field, use {{access_token}}.

Environment:
Screenshot from 2024-07-18 16-35-53

Using Postman App on Ubuntu.

Hey @amey22 :wave:

Welcome to the Postman Community! :postman:

What details are you seeing in the Postman Console when this async request is made? What status code is this returning? Is this returning the expected JSON response?

Hi @danny-dainton :smile:

I’m getting the following error while using this script, but the same doesn’t happen through the postman interface.

 The specified client_secret does not match the expected value for this client.

If you open the Postman Console, you will see that request being sent - Clicking on this will display the data (URL, Headers, Bodies, etc.).

Is that giving you any clues about anything the request that might not look right? The grant_type in the helper is also different to what you are using in the script.

I can’t see what you have in front of you so I’m just making suggestions at this point.

Can you please elaborate and give your suggestions?

They don’t look to be utterly different. Also, can’t share to protect client privacy.

The pre-request script is using:

{ key: 'grant_type', value: 'client_credentials', disabled: false }

and the Auth helper is using:

I’m not going to even begin to claim that I know everything about OAuth 2.0 but I’m sure those different types would impact things.

1 Like

This might be what you’re after:

Thanks @danny-dainton for pointing me to the post.
I tried using the same strategy as directed by @kevinc-postman, however I’m getting this error.

At which part of the process are you getting that error?

That looks like the API is responding with something. Therefore the issue is with what you are sending which we won’t be able to help with without an API specification and more details. Perhaps this is a question for the Flytnow support team.

It is not always possible to automate all OAuth2.0 grant types. The Postman Authorization helpers are doing a lot of work in the background, and includes opening a browser so you can pass the interactive parts of the login.

Are you actually testing the login process, or do you just want to test the application you hit after authentication? In which case I would recommend reading the API specification and seeing if you can indeed set it to use client credentials for authorization while you do your API testing, and then set it back to Authorization code for production. This will be down to the options for registering your application within Flytnow.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.