I have a GetOAuthInfo policy that gets the details of a refresh token generated from Internal Product which is generated from an External Product.
I don’t wanna add the resource path of the GetOAuthInfo into External Product as this would expose the API into the clients. We only want to use this internally using the Internal Product that is registered to our App 2. Where App 1 is restricted only to access the External APIs which doesn’t include the resource path of the GetOAuthInfo.
What are you really trying to do? You said you have “an Internal Product” and a proxy that is operating with that authorization wants to inquire a token that was generated “from” an External Product.
First, you don’t generate a token “from” a product.
Tokens are generated by a token-dispensing proxy. Tokens are authorized on one or more API products. Think of API Products as a wrapper around one or more API Proxies, possibly with a restriction of paths.
It doesn’t matter if the token-generation proxy is contained inside a product. The OAuthV2/GenerateAccessToken policy generates the token, and the Apigee runtime grants authorization to the token according to the settings on the APP, whose credentials are presented to OAuthV2/GenerateAccessToken.
In more practical terms, an example is:
ok, that’s the starting point.
Now, ¿what do you really want to do? Why does a proxy operating under “internal product” (??) need to inquire a token that is valid for “external product”?
The Internal Product (which is under our Internal App). Is being used by our Microservices. So, its natural for us to have an App & product with the specific credentials so that only us could access this APIs. This Internal Producf is mostly being used by our UI to make other API calls to complete a request.
Our other External Product can only access externally exposed APIs and the clients have separate Apps with their Own credentials. This cllients shoudn’t have access to our internal APIs by design. It is working fine when the Proxy (that gets the details of a Refresh Token)is in the External Product until we moved the Proxy from External to Internal Product. Then we encountered the Error InvalidAPICallAsNoApiProductMatchFound.
My issue is that, it seems to me that Apigee wants me to move the Proxy back as an External Product, all the while we need it to be accessible only to us (Internal Product). (for purposes such as debugging and getting the details of a given Refresh Token or Access Token without going through the Trace Log)
However, this internal product we have could access the same Proxy where the Access Token and Refresh Token was minted, so I don’t really see why it wants to force us to move the Proxy from Internal to External Product. Moving so would defeat the purpose of us having an Internal and External products that could otherwise be called as a list ofnaccessible of Internal and External APIs.
It is working fine when the Proxy (that gets the details of a Refresh Token)is in the External Product until we moved the Proxy from External to Internal Product. Then we encountered the Error InvalidApiKey.
What do you mean by “moved the proxy” ? Are you saying that the Internal Product contains the proxy, and the External Product does not? The inquiry or validation of an oauth token will work only when executed within the scope of a proxy that is part of an API Product that the token is authorized for.
it seems to me that Apigee wants me to move the Proxy back as an External Product, all the while we need it to be accessible only to us (Internal Product).
Apigee doesn’t want you to do anything. But it is true that Apigee works according to some rules, and you need to set your expectations to align with those rules.
GetOAuthInfo on a token, will work only if the proxy in which GetOauthInfo executes, is part of an API Product, that is authorized for the given token.
AFAIK there is no way to generally interrogate the status of a token, outside of a proxy that is included in a Product, for which the token is authorized.
I hope this makes sense.
It’s possible that you need to get a different token.
In more detail:
Suppose 2 products: External and Internal
Internal includes proxy1 and proxy2
External includes proxy2 and proxy3
Suppose a single app, App1. App1 is authorized for API product: Internal.
client uses credentials for App1 to obtain a token. This token is good for use in any proxy that is included in the API Product: internal.
Client sends in a request to proxy1. Within that proxy, GetOAuthInfo is executed. Because the token is good for proxy1 (because proxy1 is configured under Internal, and because the token is authorized for Internal product) then GetOAuthInfo works.
Client sends in a request to proxy3. Within that proxy, GetOAuthInfo is executed. Because the token is not authorized for proxy3 (proxy3 is not configured under Internal), then GetOAuthInfo fails.
I don’t know what you mean by “moved the proxy”. If you delete proxyA from the list of proxies for ProductA, and the token is good only for ProductA, then a failure in GetOAuthInfo is expected behavior, if GetOauthInfo runs as part of proxyA.
This is how I implemented it.
Internal Product includes proxy 1 & proxy2
External Product includes proxy 2 & proxy3
App1 Contains External Product
App2 Contains Internal & External Product
where
proxy1 = GetOAuthInfo
proxy2 = Issuer of Access Token & Refresh Token
proxy3 = other external APIs
What I mean when I moved the proxy, is that I moved proxy1 from External to Internal Product, then removed proxy1 from External Product to restrict access for App1 and only allow App2 to Access this API since now only App2 contains the Internal product where proxy1 resides. Both Products however has access to proxy2 and I expected it to work since what was said in the documentation was…
The resource path that is used to call a proxy with this policy (GetOAuthInfo) must be included in the Product that was used to generate the original token(proxy2). In other words, if you call the proxy with the path /tokeninfo (proxy1), then the /tokeninfo(proxy1) resource path must be included in the Product that was used to generate the token. If not, you will receive an InvalidAPICallAsNoApiProductMatchFound error.
However, App1 that generated the token doesn’t have the Internal Product to which proxy1 resides. It is only registered with External Product since App1 is allowed access to External Product only. That’s why I suspected that thing that it didn’t let me query the details of the Refresh Token which was created in App1 w/ External Product.
So, my issue is that if I put proxy1 to External Product, clients would be able to publicly access proxy1 to which is what we dont want as proxy1 should be for internal use only. It may be the reason why Apigee is not allowing me to query the details of a refresh token with Internal product is that the Refresh Token is registered with an External Product.
So the question for me really is how do I make apigee allow me to call the details of the Refresh Token using proxy1 even though it is not registered with External Product on token creation.
I already have both proxy1 & proxy2 registered on a same Product namely Internal Product. So if use the credentials for App2 it should then work since I allowed it access to the endpoints of proxy1 & proxy2. Or did I miss something?.
What do I have to do to make it work for my use case?.
Thanks for taking the time to explain. Still there is some confusion on my part or yours.
how do I make apigee allow me to call the details of the Refresh Token using proxy1 even though it is not registered with External Product on token creation.
No, as I explained, proxy1 cannot inquire the status of a token that is authorized for products that do not include proxy1. Proxy1 is not authorized for that token. Anyway why would you want to do this? It doesn’t make any sense.
Maybe you can simplify the whole scenario. Why are there two products anyway? If you have App1 with access to External Product, then a token generated via App1 credentials should be able to invoke proxy2 and proxy3 (which must invoke VerifyAccessToken). Do you have that working? If not you need to start over. Get this basic part working.
Once you have that working… If the token grants access to proxy2 and proxy3, then either of those proxies should be able to inquire the token (GetOAuthInfo) after VerifyAccessToken. (I don’t understand why you need to inquire the refresh token , but that is beside the point).
BY DESIGN, if you send that token to proxy1 which then calls GetOAuthInfo, you will see a fault: the token is not authorized. That is the intended behavior. That is the intent of tokens. They’re good for the Products/proxies you have configured.
Somehow what you are trying to do seems directly counter to the intent of the token.
“I have a token that is good for proxy2 and proxy3, and I want it to not be good for proxy1, but also I want it to be good for proxy1, sort of.” Your desire, as I understand it, is not sensible.
Maybe you could simplify it for yourself, or rethink your approach somehow, to avoid the problems you’re seeing. With the information you have now, I’m confident you’ll be able to solve this.
Good luck!