Two features exist to keep a misbehaving integration from becoming your problem, and to tell you which one is misbehaving.
Rate limiting
Two settings limit how hard a single application may fail: how many failed requests are allowed (20 by default) within a rolling window (10 minutes). Exceeding it blocks that application temporarily.
This is deliberately separate from site-wide login IP blocking. A misbehaving integration should be throttled as an application, not have its server's IP address blocked for every user behind it.
The request log
With logging on — the default — every sign-in and token request is recorded with its decision. Credentials are never recorded. This is where you look to answer: why is an application's sign-in failing, which application is generating failures, and did the user actually reach the consent screen.
The five common integration problems
- The return address does not match. Matching is exact — a trailing slash,
httpinstead ofhttps, or a different port all fail. By far the most common. - PKCE is missing. A public application must use it.
- The application is asking for something it is not allowed.
- The grant is not enabled — check both site-wide and per-application settings.
- Signature checks failing at the far end — almost always an application with a signing key copied into its configuration, after a rotation.
Housekeeping
The request log grows with traffic. Include it in whatever routine you already run over the other logs.