Is there a way in APIGEE X to know if an API is being used by web application or by Mobile app?

[Ashishkumar2]

Hi,

I am looking to restrict API integration for a user depending on whether the API is being consumed by a Web application or a mobile application. Is there any way in APIGEE X to know that?

We want to do different authentications for the API depending on where the APIs are being used.

Thank in advance.

[dchiesa1]

Yes , sort of, but not authoritatively.

You can use the user-agent header to determine what the browser or user agent is.  If it's an iphone running Safari, then you'll get a particular user-agent.  If it's a program built in Java for the Android, it will have a different user-agent. 

The issue is those user-agents are not authenticated data.  The values are voluntarily provided and they can be spoofed.  Just try it!  Use postman or curl and you can set the user-agent to whatever tyou like. 

Therefore the serving endpoint, the API proxy in this case, cannot rely on the user-agent for enforcement of security controls. It's a hint as to what device or client the user is employing, but it's just a hint. 

Can you explain to me how/why  you "want to do different authentications for the API depending on where the APIs are being used". Elaborate more on that please?

[Ashishkumar2]

We want to do different API authentication and integration based on if consumer side has end-user or M-M. For M-M, apart from just using clientID and secret, we want to do some sort of authentication. We can't ask all our external clients to do certificate.

[dchiesa1 · Accepted solution]

Maybe consider, for your machine-to-machine scenarios, using a grant type like jwt-bearer.  (See RFC 7523) That eliminates the need for transmitting secrets, and eliminates the need for a shared secret completely.  Basically in the request-for-token, the client sends a JWT signed with RS256 or PS256.  Apigee validates the signed JWT, before issuing a bearer token.  

Each client would get its own RSA key pair.  The client would possess and store the private key, and Apigee would store and manage the corresponding public key for each client.  (Apigee won't need the private key). This eliminates the need for a certificate for each client app.  And it provides  better security than a grant type based on transmitting a clientid + secret in the request-for-token.  

If this is what you do, then... you don't need to change much on the Apigee side. You need two token dispensing endpoints - one for users, and one for the M-to-M case.  For the user case you will want to use OpenID connect or something like that, I guess.   Or a modified "Password" grant, using an already-issued ID token as the user credential. 

In both paths, user or M-to-M, the result is... an OAuth token.  And so subsequent calls just present the token, and Apigee uses OAuthV2/VerifyAccessToken, and everything is good.

 If you still need or want mTLS for the M-to-M scenario, then... you need to modify your "verify" logic on the Apigee side to inspect the inbound token and do different things depending on whether user or M-M.  And you'd need a separate Load Balancer -one that supports mTLS for yuor M-M case, and 1-way TLS for the user cases.