Cookie Settings
Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Other cookies are those that are being identified and have not been classified into any category as yet.

No cookies to display.

91d47680 authorisation

OAuth 2.0 Protected Resource Threats


This is part of a larger series on OAuth 2.0 Threats. The other parts are linked below.

  1. OAuth 2.0 Threat Model and Security Considerations
  2. OAuth 2.0 Client Threats
  3. OAuth 2.0 Authorisation Endpoint Threats
  4. OAuth 2.0 Token Endpoint Threats
  5. OAuth 2.0 Refresh Token Threats
  6. 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, 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) 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 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.