# OAuth 2.0 Token Endpoint Threats

- Link: https://www.agilicus.com/oauth-2-0-token-endpoint-threats/
- Published: 2021-01-12T06: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 Token Endpoint creates and transmits an access token to a client. Any eavesdropping
here will give (limited by your scope) access to the bad actor.

As a mitigation, always use TLS. Use a public Certificate Authority. Never allow
insecure mode or self-signed certificates. Avoid using wildcard certificates. Keep
the encryption all the way to the token endpoint. Use [Defense In Depth](https://www.agilicus.com/firewall-defense-in-depth/).

Many OAuth 2.0 implementations maintain state. This might be in an in-memory Key-
Value database (e.g. Redis), or, could be in a relational database (e.g. Postgresql).
This state sture must be even more secure than the transport: any loss of this information
gives ***all*** the access tokens.

In addition, the Token Endpoint could be a convenient way for an attacker to do 
password stuffing: guessing client-id/password pairs. A [Fail-2-ban](https://www.agilicus.com/fail-to-ban/)
approach can be a low risk, low-complexity, high-effective risk reduction to this
approach.