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 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), 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 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 fileystems. Protect against the east-west threat from other services in the same domain or scope or cluster.