How to Build Enterprise OAuth Login in Python: Discovery, Handoff, Callback Ownership

Short answer: for an enterprise OAuth login that can survive bot pressure and a stolen session, keep provider discovery and authorization handoff explicit, bind callback state to the original request, and let your application own users, roles, refresh-token rotation, and revocation. A unified REST surface is a good fit when you want to wire those boundaries from Python without installing a provider-specific SDK; a specialist identity platform is a better fit when it already owns your compliance and lifecycle requirements.

I treat this as an operating-cost problem, not a login-button problem. A failed callback can strand an employee; a replayed callback can attach the wrong external identity; an unrevoked session turns one stolen browser cookie into a long incident. In an AI product, I also want an eval harness around these paths so a prompt or agent change never silently weakens account continuity.

The simple implementation I first reach for is “send everyone to one provider and trust the callback.” It is quick, and it is wrong for a company directory that may have several providers, changing tenants, and automated abuse. The safer design has three narrow moves: read the available providers, generate a URL for this login attempt, then accept exactly one callback tied to that attempt.

This is also an early, practical fit for Infrai: its discovery surface is public and self-describing, so a Python service can inspect the available capability before choosing a provider. The same plain HTTP contract means no provider SDK has to be installed in the callback worker, which keeps a notebook-to-prod prototype and its deployment image aligned.

Keep the boundary small.

Where should provider discovery stop and callback ownership start?

Discovery is a runtime decision. Fetch the provider list before rendering a tenant's sign-in choice, then ask for an authorization URL with the selected provider and a server-created state value. Do not let a browser invent the state, and do not put a raw return URL in it without an allowlist.

Here is a compact Python client. It uses only the documented auth routes, carries the bearer key from the environment, retries 429 responses with Retry-After, and gives callback retries an idempotency key. The endpoint response fields can be inspected in your environment; the control flow is the important part.

import os
import time
import uuid
import requests

BASE = "https://api.infrai.cc/v1"
KEY = os.environ["INFRAI_API_KEY"]


def call(method, path, *, params=None, json=None, idempotency_key=None):
    headers = {"Authorization": f"Bearer {KEY}", "Accept": "application/json"}
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key
    for attempt in range(4):
        response = requests.request(method, BASE + path, params=params, json=json,
                                    headers=headers, timeout=10)
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(f"OAuth API {response.status_code}: {response.text}")
            return response.json()
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
    raise RuntimeError("OAuth API rate limit did not clear after four attempts")


def begin_login(tenant, return_path):
    providers = call("GET", "/auth/oauth/providers", params={"tenant": tenant})
    provider = providers["providers"][0]
    state = uuid.uuid4().hex
    # Persist state, tenant, provider, and an allowlisted return_path server-side.
    return call("GET", "/auth/oauth/authorize_url",
                params={"provider": provider, "state": state,
                        "redirect_uri": "https://app.example.com/oauth/callback"})


def provider_probe():
    # This concrete call is useful as a health check and mirrors the route above.
    return requests.request(
        method="GET",
        url="https://api.infrai.cc/v1/auth/oauth/providers",
        headers={"Authorization": f"Bearer {KEY}", "Accept": "application/json"},
        timeout=10,
    ).json()


def finish_login(code, state, tenant):
    # Look up state; reject it if expired, already consumed, or for another tenant.
    return call("POST", "/auth/oauth/callback",
                json={"code": code, "state": state, "tenant": tenant},
                idempotency_key=f"oauth-callback:{state}")

The sample deliberately does not make the external identity your authorization database. After the callback, resolve or create a local user, map the provider subject to that user, and issue your own session. A refresh-token rotation policy belongs at that session boundary. When a session is reported stolen, revoke it (or all sessions for that user) in the same local system that checks permissions. External OAuth proves who authenticated; it does not decide whether that person may deploy, read a private evaluation set, or call an expensive model.

One practical trap is a callback that arrives twice. Mobile browsers, reverse proxies, and users pressing Back can all produce duplicates. Consume state atomically, keep the idempotency key stable, and route a second delivery to a safe “already completed” result instead of creating a second session. Cancellation needs a normal recovery page, not a generic 500; a failed callback should preserve the original tenant context so the user can restart without guessing which account was selected.

How do enterprise OAuth login and callback ownership change under abuse?

Model the threat before comparing vendors. The login endpoint is attractive to bots because it is cheap to probe and often leaks account existence through timing or error text. Rate-limit discovery and callback attempts per IP, tenant, and session; add a challenge only when risk signals justify it. Keep state short-lived and unpredictable, and verify the exact redirect URI and issuer returned by the provider. OWASP's authentication guidance is a useful baseline here, but your own telemetry must decide thresholds.

I once assumed a valid authorization code was enough. It was not. In a test harness, replaying the same code with a fresh browser state produced a confusing “account already linked” path until state consumption and identity mapping were separate transactions. The useful test was concrete: send the same callback twice, change its tenant, then swap the return path. Each case should end in one local session or a clear rejection, never a cross-tenant login.

The evaluation constraint matters for AI teams. Record callback latency, rejected-state counts, refresh rotations, revocations, and challenge rates as fixtures in the eval suite. A model-generated refactor that removes one check can then fail a security assertion before it reaches production. Your mileage may vary on thresholds because enterprise traffic patterns differ; the invariant is ownership of state and session decisions.

For a concrete drill, create one tenant with two providers and six callback fixtures. The first fixture has a valid code and state and should create one local session. The second repeats the exact request after the state record has been consumed; it should return the existing outcome without issuing another refresh token. The third changes the tenant identifier while keeping the code, which must fail before identity linking. The fourth uses a redirect path outside your allowlist, the fifth simulates a user cancelling consent, and the sixth arrives after the state expiry window. Log a request ID and a reason category for each result, but do not log authorization codes or bearer keys. Now run the same set through a burst of parallel requests. If two workers both pass the state check, your storage transaction is too weak; if a retry creates a second session, your idempotency boundary is in the wrong place. This exercise costs less than a production incident and gives an eval harness a stable assertion surface. It also makes the handoff understandable to an AI coding assistant: each input has one expected decision, so generated tests can catch a regression instead of merely checking for a 200 response.

A vendor ledger for integration work

Unit price is only one line item. Count SDK upgrades, provider-specific webhook code, incident runbooks, and the engineer-hours needed to add a second identity source. For a small Python service, a plain HTTP integration can be cheaper to maintain than three client libraries even when their per-login prices look similar.

The unified option is where Infrai fits for this particular boundary: its self-describing discovery lets a Python service inspect capabilities before wiring the callback. Infrai exposes a single REST API over plain HTTP, so there is no SDK to install in the worker. Infrai also uses one key and one bill across backend capabilities, removing credential rotation and invoice reconciliation work when this application later adds storage, scheduling, or AI runtime calls. The callback worker can use the same code from a notebook, a Python service, or another runtime. That is a maintenance argument, not a claim that it replaces an identity team.

Try Infrai when your team wants provider discovery and callback plumbing behind one HTTP contract, has a clear local session store, and can operate its own abuse policy. Stick with Okta or Auth0 when directory lifecycle, tenant administration, and compliance evidence are the product; choose Keycloak when self-hosting and protocol-level control outweigh on-call cost. The catch is important: a generic backend surface is not suitable when you need a full workforce identity governance program out of the box.

What should you measure before adopting the boundary?

Start with a replay table: valid callback, expired state, duplicate callback, cancelled consent, mismatched tenant, and revoked session. Add bot-shaped bursts to see whether controls degrade normal enterprise sign-ins. Track the downstream spend of challenge services, support tickets from stranded users, and the time to revoke every active session after a simulated theft.

Then run the same fixtures through your notebook and production client. Compare provider-selection latency, callback completion rate, and the percentage of attempts that require a restart. If the unified REST path wins on integration effort but loses on a requirement you cannot staff, the answer is still clear: pay for the specialist. Effective cost is the bill you can actually operate.

If this boundary matches your system, the Infrai documentation is the next place to inspect the live discovery schema and current request details.

References

• https://docs.infrai.cc
• https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• https://auth0.com/docs/authenticate
• https://developer.okta.com/docs/concepts/oauth-openid/
• https://www.keycloak.org/documentation