# OAuth 2.0 Protected Resource Threats

- Link: https://www.agilicus.com/oauth-2-0-protected-resource-threats/
- Published: 2021-01-14T06:00:00+00:00
- Author: Don Bowman

This is part of a larger [series](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations)
on OAuth 2.0 Threats. The other parts are linked below.

 1. [OAuth 2.0 Threat Model and Security Considerations](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations/)
 2. [OAuth 2.0 Client Threats](https://www.agilicus.com/oauth-2-0-threat-model-and-security-considerations-1)
 3. [OAuth 2.0 Authorisation Endpoint Threats](https://www.agilicus.com/oauth-2-0-authorisation-endpoint-threats/)
 4. [OAuth 2.0 Token Endpoint Threats](https://www.agilicus.com/oauth-2-0-token-endpoint-threats/)
 5. [OAuth 2.0 Refresh Token Threats](https://www.agilicus.com/oauth-2-0-refresh-token-threats/)
 6. [OAuth 2.0 Protected Resource Threats](https://www.agilicus.com/oauth-2-0-protected-resource-threats/)

Finally we get to the protected resource itself. The OAuth 2.0 client and server
have done their work, an access token has been generated. If the Access Token is
a [JWT](https://www.agilicus.com/jwt-token-is-you-on-the-wire/), ensure that the
resource always validates it against the signing authority, otherwise it is useless.

Consider using a single-point enforcement (an Identity Aware Web Application Firewall,
an [API Gateway](https://www.agilicus.com/using-single-sign-on-oauth2-across-many-sites-in-kubernetes/))
so that you can have a single location of audit, of logging.

If using a JWT-based access token, you can encode the scopes inside it, and, the
protected resource can be involved in ensuring those scopes and the request are 
correct.

Consider using simple schemes like [Cross-Origin-Request-Sharing](https://www.agilicus.com/cors-and-you/)
to ensure the clients are using the access token appropriately.

Also consider, can the resource itself be spoofed? E.g. could the user be encouraged
to send a connection to a fake resource, and thus expose their access token? TLS,
Certificates, well written clients are your defense here.

Also, from an east-west perspective, the client might use the same access token 
for more than one resource. If one of the resources becomes compromised, will it
use the access token on behalf of the user to access another resource? Protect against
this with resource-specific access tokens and scopes.

Your security infrastructure might itself be used against you. Have you put in a
place a TLS-inspecting firewall? Does it log lots of useful information for later
forensics? Does this include the Authorization Header? This means that the log infrastucture
now must be secured at a higher level than everything else combined.