API Verification Workaround

Google Cloud Apigee
, ,
1

Hi,

I would like to check with experts for my below defined apigee token verification trick/workaround. I have 2 proxies.

  1. generate token
  2. verify token

and products

  1. p_verify_token
  2. p_other

and applications includes these products

  1. a_verify_token
  2. a_other

With this setup, I would like have a special service (token verification service) that performs based on 2 different tokens.

  1. a_verify_token app’s token. Where the special service has it’s own creds to generate tokens via apigee.
  2. a_other app’s token. Arrives at the service in a special header configured via AccessToken tag.

So, when a request arrives at my special service. A regular VerifyToken will be processed and service will be authorized for further processing. Then another VerifyToken will be processed and extra a_other_app’s token verified. Here is the trick begins; as per defined in this link by @dchiesa1 I had to include the verify product on each app that requires to work with this specific service. Otherwise InvalidAPICallAsNoApiProductMatchFound error thrown.

Instead of adding the verify proxy to all products related to client apps, I have debugged and see that the verification process checks token integrity (valid, not expired etc…) first then performs a check for product. So I decided to implement FaultRule, where I can say a token is valid (for my business) only if the error is InvalidAPICallAsNoApiProductMatchFound.

Simply put the proxy looks like this. There is a regular VerifyAccessToken hook which is not seen here.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <FaultRules>
        <FaultRule>
            <Step>
                <Name>SuccessResponse</Name>
                <Condition>
                    fault.name = "InvalidAPICallAsNoApiProductMatchFound"
                </Condition>
            </Step>
            <Step>
                <Name>FailResponse</Name>
                <Condition>
                    fault.name != "InvalidAPICallAsNoApiProductMatchFound"
                </Condition>
            </Step>
        </FaultRule>
    </FaultRules>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>VerifyClientToken</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>

Is this too tricky ? most probably an anti-pattern :slightly_smiling_face:

2

take care if you employ that approach.
it will work, I guess - based on your observation and testing. But it depends on an internal implementation detail: that the token is first verified and THEN checked for an appropriate API Product match. That seems like the only rational order for the two checks, and so I suppose you could rely on that ordering not being changed in the future, even though it is not documented to behave that way.

what are you really trying to accomplish with that fault rule? Could you use a JWT to meet your goal ?

3

Thanks for the reply. Yes, JWT is a good match for this scenario, but company does not want to utilize it.

Why do I need it ?

I have an app that, it has sole purpose of verifying the token. It is not behind apigee ( uploader app with huge files where size exceeds apigee limits). That app has it’s own credentials to generate a token on apigee. Plus, as per it’s function, it will receive a token from the calling party to validate. I just don’t want to add the verify-proxy to all products, but If I don’t do that than 2nd verify token policy (clients token) fails. Not sure If I could of made myself clear. If not, I will share a diagram too :slightly_smiling_face:

p.s : final token flow changed a bit more following the initial post :slightly_smiling_face: