Testing multiple user credentials - unauthorized 401 error

[apy2k]

New here and using Postman for Troubleshooting API customer calls. So I am not a developer, these are tried and tested APIs in use and never usually have issues.

The errors being experienced are unique to support staff such as myself where it is common to switch within Postman to different user keys and secrets for OAUTH. I know that you can clear cache, clear open tabs, and clear the contents of the APIKEY field in the environment.

However, even after these steps when you OAUTH and run the API for a different customer there is the failure because somewhere the APIKEY being used is still the same KEY from the previous test.

The only way to stop this I have found so far is to paste the KEY for the current customer you are testing into the Environment APIKEY field and then try again.

In spite of the fact it appears that the APIKEY is not still cached anywhere the previously used Key is still being used, which I can also see when tracing the connection in Apigee.

Hopefully there is some way to force the contents of the APIKEY field to actually clear, any suggestions?

[danny-dainton]

Hey @apy2k

Welcome to the Postman community!

Do you know if you have a variable of the same name, in a different scope (Collection/Global/Environment)?

Are there any variables being used within any of the Auth Helpers that might be being inherited by the percent?

It would be good to get some visual examples (masking the sensitive data) of what you have in place in the Collection to try and get to the bottom of the problem.

[apy2k]

Thank you Danny, I will try and post what is helpful, bear with me if the info doesn’t help enough.

What I have is an Environment where the following should I presume populate from the OAUTH:
apikey
token

The OAUTH takes the key and secret and I see the usual successful messages returning things like the user email etc confirming this is the right account.

Then I have multiple users in Collections. So after the successful OAUTH, the API that runs, which basically gets a price on a product you specify. The API is set in the Authorization tab to “inherit auth from parent”. The Params are the customer account number, and the product code.

The customer account number has also been specified in the OAUTH phase also in a scope field under the body. screenshot below of what you see in headers on the API:

If you hover over apikey you see nothing populated in apikey. and yet somehow the credentials being used are still the previous customer you tested.

Until you copy and paste the new customer apikey in the current value in the apikey field under the environment this will continue to fail. Customers themselves will never see this error because they never switch between accounts.

As a support person I troubleshoot customers all the time so its a unique issue in the scenario where you test one customer then switch to another. even after clearing the cache, restarting postman etc something still seems to be held in cache and defaulting to the key previously used unless you force the new key by editing the current value in the environment.

[danny-dainton]

Hey @apy2k

I’m just trying to clarify this in my head, it’s tricky to follow from the information - I think it might be down to some of the terminology being used

You keep using the term The OAUTH or OAUTH phase - What is the structure of the Collection? How many requests are help within it?

Are using anything at the Collection Level that could be picked up by the requests which have the “inherit auth from parent” set.

Are you running the Collection manually, one request at a time or are you using the Collection Runner?

Are there any pre-request scripts added to the Collection or Requests that could be setting anything auth related at runtime?

You mentioned clearing the cache - How are you doing that step?

Apologies for all the questions - It would be easier if I could see what you have in front of you as I would be easier to see what’s happening but I’m relying on your information and any full app screenshots (Cropped image miss vital parts) that you can share, without posting anything sensitive,

[apy2k]

Thanks, you can tell I am fairly new to this. So I am referencing things that are probably custom for my company so when I used the term OAUTH I am assuming its a generally used term. I’ll try to paste something useful here below.

OAUTH:

username and password is the key and secret

This is run first

Then the GET PRICE API

set to inherit from parent
headers as per my previous message
I can’t put additional screen shot there as posts seem to be limited to 3 images, but hopefully that’s enough info.

So yes one manually after the other, the OAUTH first then GET PRICE. As far as I am aware there should be no other pre-request scripts.

also the clear cache i did was clicking the top left hamburger icon and then Help - clear cache and reload

[michaelderekjones (Mike Jones)]

Your authentication looks strange and appears to be mixing authentication.

You appear to be mixing an OAuth grant type of client credentials with a username\password.

There is no username\password in a client credentials OAuth flow.

I can’t see where your client_ID and client_secret is set. Which would normally be in the body alongside the grant_type and scope. It’s required for client_credentials authentication. This is what replaces the username and password.

Unless the username and password is just to control access to the OAuth token end point with basic auth. (Which sounds unusual and is not something I’ve seen before).

The ultimate goal should be to produce a token which you save to an environment\collection variable, which I suspect should be used as the bearer token for the GET PRICE request.

Not sure where the API key would come into this, unless that is extra security for your API. You usually, just need the bearer token.

Client credentials is commonly used for server-to-server interactions that must run in the background where no user is involved in the authentication.

The key bit here is that the application has the permissions, not the user. Therefore, I’m not sure how you would be able to switch customers unless you have different a client_id (and matching
client_secret) for each customer.

If you want to test logging on with different credentials, I would change the OAuth grant_type to password instead of client _credentials (if your API supports it). You still need the client_id and client_secret and it will still generate the bearer token, the same as before.

This is what I use to test different accounts\permissions sets.

Then you would just have different environments for the various clients (with the appropriate usernames and passwords).