OAuth2.0 not inheriting properly

I am migrating from Postman to Apidog and when I imported my project, configured variables, and setup the parent OAuth2.0 initially, it inherited to all the endpoints as expected and I thought that was it. But now that the first token that was valid has expired I am unable to get a new token to inherit properly. The OAuth2.0 workflow works properly, I get a token. But while all my endpoints are configured to inherit from parent, they all seem to be stuck on a Bearer token that I cannot find configured anywhere and it is always used instead of the one that the parent holds. Even if I delete the token from the parent auth, the endpoints, still configured to use the parent auth, try to send the same old Bearer token. I have looked for global variables and headers (none are set for either). I suspect I am doing something wrong, just not sure what.

Thank you for your feedback. We’ll look into the issue you reported.

Just to let you know, our current OAuth 2.0 functionality isn’t perfect yet. We’re working on an upgrade to improve OAuth 2.0 features, which is expected to be released this month. The new version will make OAuth 2.0 more complete and easier to use.

Understood. My company is looking for an alternative to Postman that gives us the same flexibility but also ensures our projects are able to be secured and HIPAA compliant (our config under our control, not in a cloud). It appears as a legitimate bug in the inheritance but not being familiar with Apidog beyond a few days, I suspect it is something I have misconfigured somewhere.

Apologies, I should have included this information – I am on Mac (silicon) using the desktop application.

Could you please share screenshots of your root directory Auth settings and endpoint settings? We haven’t been able to reproduce this issue yet.

Parent Auth config

Child Auth config

Advanced options for parent Auth config

It is worth noting that when I replicate the parent Auth config to the child Auth config, the child is able to connect successfully first via oauth endpoint then via its’ configured endpoint

Could you please share your Apidog version number? We’ll try to reproduce and locate the issue, then get back to you promptly.

image.png

We still haven’t been able to reproduce the issue you’re experiencing. Could you please export your Apidog project data (after removing any sensitive information) and share it with us so we can investigate further?

I’ve exported two endpoints. authenticate_sso is configured to inherit parent auth while session is configured to do its’ own auth (configured same as parent).
FOCOS_External_API.apidog.json|nullxnull

Let me double-check. Is the issue you’re encountering as follows: You want to configure OAuth2.0 at the root folder, but the Access Token used for each endpoint might be different?

If that’s the case, as mentioned earlier, the current OAuth2.0 configuration isn’t fully perfected yet. Currently, the OAuth2.0 settings for endpoints will completely inherit both the configuration and Token from the parent folder if auth type is Inherit. We plan to support configuring Access Tokens at the endpoint level in future updates.

Regarding your observation that “endpoints still use the Token for requests even after deleting it from the folder” - this occurs because the inherited values are cached. After removing the Token from the folder form, you need to save the folder configuration for the changes to take effect on the endpoints.

I see what the issue is now. It is a misunderstanding in workflow. I was unaware that every time I obtain a new token I must save the root OAuth2.0 settings. And for clarity, no, I did not want different tokens for each endpoint; I wanted the current token root holds to be applied to all endpoints. This would also apply to refreshed tokens (they should inherit similarly). It is working for me now, though having to save after each time I get a new token seems unintuitive (and perhaps is being worked on?). Thank you for the help!

Thank you for your feedback. We’re currently working on improving this feature.

Thanks to this thread and losing a few hours debugging I had the exact same issue. Was not at all aware to save the root config then go and make my API calls. could we ask that the UX be improved on this. We too are evaluating moving from postman to apidog and this has been the only issue we found so far.

Thank you for your feedback. I’ve shared it with our product team, and we’ll work on improving the UX in this area to make it more intuitive.