kinlane
commented
6 years ago Hey Neil,
Hope all is well.
This is definitely a concern, as well as a reality for delivering any web, mobile, or device application on your API.
I regularly encounter folks who have APIs driving mobile apps, and don't realize this is a reality, and I simply run their mobile app through a proxy and change their view of the world. ;-)
Encryption is always first line of defines to keep people from sniffing in transit. However, I can also terminate, and use a self-signed cert -- common proxy practice both for good and bad reasons.
You could use SSL pinning in your apps, which reduce man in the middle attacks, but I've seen people get around this too.
In the end, you should always assume ALL tokens are eventually compromised. Whether it is simple key, OAuth, or JWT, they should be recycled, refreshed, and stored in app, and transmitted securely.
In the end, you can always stop the behavior you discuss -- the goal is to just authenticate with diverse range of fingerprints, 1) token, 2) IP Address 3) User-Agent 4) Other.
Have an API management layer in place that can identify healthy web, mobile, and device activity patterns, and shut down tokens who don't fit these patterns.
Have an API management dashboard where you can watch and understand usage. Have automated systems that respond and turn off tokens when bad behavior is occurring.
Have ALL APIs in logical API plans, enforced by the API gateway and management layer, and have API rate limits for ALL tokens, no matter who they are issued to or for.
Hope that helps.
Thanks!
Kin Lane
Kin Lane API Evangelist http://apievangelist.com kin@apievangelist.com @kinlane https://twitter.com/kinlane
On Fri, Aug 17, 2018 at 9:16 AM, Neil McKechnie notifications@github.com wrote:
Kin, a little out of scope for HSDA, but do you have recommendations for securing access (authentication) to an API endpoint in scenarios where the API consuming app might not be entirely secure and user authentication is not relevant, like a public mobile app or web browser?
That takes the full OAuth2 flow out of consideration (no end user to login). One could still issue an access token to the application but it could easily be compromised by just doing a View Source of the HTML or using dev tools such as in Chrome. In that scenario you would have unauthorized third parties in possession of your access token and thus able to nefariously hit your API endpoint.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openreferral/api-specification/issues/80, or mute the thread https://github.com/notifications/unsubscribe-auth/AADbJJivRhA67Y8CS8Be6zQ99Sznt-kTks5uRuxPgaJpZM4WB1FT .
NeilMcKLogic
Kin, a little out of scope for HSDA, but do you have recommendations for securing access (authentication) to an API endpoint in scenarios where the API consuming app might not be entirely secure and user authentication is not relevant, like a public mobile app or web browser?
That takes the full OAuth2 flow out of consideration (no end user to login). One could still issue an access token to the application but it could easily be compromised by just doing a View Source of the HTML or using dev tools such as in Chrome. In that scenario you would have unauthorized third parties in possession of your access token and thus able to nefariously hit your API endpoint.