This is part of a larger series on OAuth 2.0 Threats. The other parts are linked below.
- OAuth 2.0 Threat Model and Security Considerations
- OAuth 2.0 Client Threats
- OAuth 2.0 Authorisation Endpoint Threats
- OAuth 2.0 Token Endpoint Threats
- OAuth 2.0 Refresh Token Threats
- 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.
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 approach can be a low risk, low-complexity, high-effective risk reduction to this approach.