A recent paper, Signing into One Billion Mobile App Accounts Effortlessly with OAuth 2.0, describes a seemingly new security flaw in the implementation of single sign-on over OAuth 2. As an API developer, should you be worried? You may be wondering if you're affected and how to mitigate the issue. Indeed, you might not even be sure what the issue is.
Consider this scenario. You have a mobile application that allows users to sign in through Facebook. Your mobile application talks to your API and can pass in an OpenID Connect JSON Web Token (JWT) to authenticate to your API, and you've secured these communications over TLS. Your API looks at the claims in the JWT to decide whether to grant access. What could go wrong? In this case, what goes wrong is that a man-in-the-middle proxy changes the claims -- specifically the subject claim -- in the JWT when it comes back from Facebook. Your API trusts your mobile app, and your mobile app happily passes along the modified JWT. Your API reads the new subject claim and grants access to the identifier there, as opposed to the user who actually authenticated to Facebook. Congratulations! You've just granted access to an arbitrary user. How? No one in the chain of trust verified the JWT by checking the signature or by passing it to a validation endpoint at Facebook.
This is the crux of this vulnerability. Your API cannot trust identity claims made by other systems, even systems you wrote, because they may be subject to attacks you did not anticipate. Your API must always check the validity and current authority of any security tokens passed in from clients, even if you believe that client could not possibly be exploited. In short, your API can't trust anyone to do one of its key jobs -- authentication -- for it. The moment you delegate that responsibility to another system, you may shave a bit of time off your API calls, but you have exposed you, and your users, to significant risk.
The solution to this vulnerability is to ensure that your API services check any and all security tokens, no matter where they've come from. You need to validate the signature of a JWT to make sure it wasn't tampered with before it got to you. If you use OAuth 2 instead of OpenID Connect, you need to pass any Bearer token to a token validation endpoint provided by the identity provider to get the user to which the Bearer was issued; do not trust the client's claim about the user to and for which a given Bearer token was issued.
Thankfully, API gateways, when properly configured, can solve this problem for you. The CA API Gateway, for instance, has an assertion that can validate a JWT signature, and the routing and orchestration capabilities can be used to verify and collect user authentication and authorization data from an identity provider. You can even pull these checks out into a policy fragment that can be applied to all of your OAuth 2 services. Other API management solutions offer similar functionality.
In the end, the security of your API is its own responsibility, and it should always hew to this classic security advice: Trust No One.