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 Authorisation Endpoint 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

The front-door of your OAuth 2.0 authorisation system is the Authorisation Endpoint. This should be well-known and documented (ideally with an OpenID Discovery Document), so don’t even think about security by obscurity.

Your first line of defense is TLS and Certificates. Use a public-signed certificate for your OAuth 2.0 Endpoints. Never use self-signed certificates. This is your primary defense against DNS poisoning, ARP spoofing, doppleganger domains, etc. If a bad actor can encourage your users to hit a counterfit authorisation server, they could use this to steal password information. In your client, always verify your TLS certificates, never allow bad or self-signed.

An Authorisation Server may ‘cache’ information on previously authorised clients. This can be used to reduce the computational cost, to reduce the user complexity. But, it leaves a replay attack open. You can protect against this by limiting the number of access tokens which may be (re) issued, by forcing pre-registered public redirect URI.

As with all services, use a set of best practices. Never use wildcard TLS certificates. Use read-only fileystems. Protect against the east-west threat from other services in the same domain or scope or cluster.