#Restriction of API by App (bundle name or fingerprint)

4 messages · Page 1 of 1 (latest)

severe jungle
#

Working on a problem. We have mobile APIs in our Laravel Project and we want to restrict the usage, so specific apps can access
What are the best solutions y'all have implemented, any best practices?

I have researched a bit on restriction per app signature, but I am not sure if they manually can send app signature, and if yes, then will anyone be able to send that App Signature (fingerprint)

Like if we restrict that specific App Bundles can access the API, if soemoe else sent the request with that bundle, will that work?

jade mountain
#

Not really sure what you're asking, but I think what you're referring to is PKCE (or similar) auth? https://laravel.com/docs/12.x/passport#code-grant-pkce
AFAIK then you'd make a client in your backend, then set the client-id on your app, so that way you can only authenticate if with that client. You could then make multiple clients (multiple apps), each having their own ID.

If you're talking about intercepting the request on a mobile device and then replaying it, with the same access token, then there's not a whole lot to do. There's only a handful of apps that really try to combat this, like Instagram. But it's a cat and mouse game, when people find out how some secrets are generated on the device, then Meta updates the app with a new technique. It's an endless battle basically.

severe jungle
#

Got it @jade mountain
That answers my question. Yes, I was talking about how can we restrict the app requests, if someone could replicate that. If apps like Instagram are facing this issue then... I dont know what to say...

Thank you

jade mountain
#

I didn't mean to say you shouldn't do anything about it, but more like, if people want to call the API outside of your app it would likely be possible. That isn't to say you can't build in safe-guards, like Play Integrity / App Attestation, or even simpler things like pinning the token to a client with some sort of device fingerprint that's signed. This would make it a lot more difficult to reuse tokens.

It's also a matter of how important is it. A token is tied to a user, so all the users does is the same he can do within the app itself. If there's no harm in that, or no harm in them not strictly doing it through the app, then I'd say it's probably wasted time