# OAuth 2.0 Authorisation Endpoint Threats

- Link: https://www.agilicus.com/oauth-2-0-authorisation-endpoint-threats/
- Published: 2021-01-11T06: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/)

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](https://openid.net/specs/openid-connect-discovery-1_0.html)),
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](https://www.agilicus.com/dnssec-2-factor) 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](https://www.agilicus.com/have-you-set-your-security-context-recently/)
fileystems. Protect against the east-west [threat from other services](https://www.agilicus.com/defense-in-depth-securing-your-new-kubernetes-cluster-from-the-challenges-that-lurk-within/)
in the same domain or scope or cluster.