# OAuth 2.0 Authorisation Endpoint Threats

This is part of a larger [series](/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](/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](/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.