# OAuth 2.0 Token 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 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](/fail-to-ban/) approach can be a low risk, low-complexity, high-effective risk reduction to this approach.