See the device before you trust the session

A successful sign-in and a compromised sign-in look identical until you need to explain one to a customer. By then you want three things already in place: a signal from the device, a policy that can react, and levers the user—not only your admins—can pull when access should stop.

October's Authdog releases cluster around that idea. Device intelligence and fingerprints tighten hosted sign-in. Connected Apps and Agent Sign-In extend OAuth in directions MCP and agent products expect. MCP Auth settings finally give you a default resource when a client skips RFC 8707. This post walks through what shipped, how the pieces fit, and where to start.

Device intelligence: policy at the front door

Password, signup, WebAuthn, and session checks now share a device telemetry path. Your environment can define device intelligence policies that decide what to do when signals look off—require step-up MFA, block, or allow while you record what was seen.

That is not a replacement for MFA or bot detection. It is an extra layer that runs with them on the identity host, so the same sign-in flow your users already hit can change behavior without a separate "risk API" integration.

Configure policies under Security for the environment, then exercise a sign-in you expect to challenge. Confirm the audit trail shows the policy outcome you intended.

Known devices: fingerprints users can revoke

Alongside policy, Authdog now keeps a stable device fingerprint on participating sign-ins. The signed-in user sees known devices in the profile and can revoke one; operators still have the full directory in the console.

Revoking a device is a user-scoped control: it stops new sessions from that fingerprint's perspective, not a global ban on the account. Pair it with session management when you need to clear active sessions too.

Trust boundary worth stating plainly: fingerprints are environment-scoped signals, not hardware attestation. Treat them as strong hygiene for account takeover response, not as proof of physical possession.

Connected Apps users can revoke themselves

Connected Apps started as an admin view of OAuth grants. The gap was always the end user who authorized Claude, a mobile app, or your own product client—and who should be able to disconnect without opening a ticket.

The hosted account portal now lists OAuth clients the user consented to and calls identity /api/v1/connected-apps to revoke. The console profile exposes the same list for operators who sign in as themselves. Revoke marks consent withdrawn and invalidates live access and refresh tokens for that client and user.

That is the same consent store the authorization server already used; the change is self-service surfacing, not a second registry.

Agent Sign-In: registered clients for accountable apps

Agent Sign-In (agents as OIDC subjects with enrolled keys) stays the open-client path for https-origin RPs. Registered clients add the tier product teams ask for when an app needs a confidential client_id, a one-time secret, up to ten redirect URIs, mandatory PKCE, and optional owner claims (owner_sub, owner_name, owner_email) for the human accountable for the agent.

Register from Agents → Sign-In in the console or via registerOidcClient with agentSignIn: true. Owner scopes are ceiling-gated to registered clients; open clients cannot request them.

Headless approval (accept_disclosure on the waiting-page approve API) remains the path for automation that cannot click through hosted consent. See Agent Sign-In for lifetimes and claim tables.

MCP default resource (dedicated note)

If you ship MCP tools and legacy clients omit the OAuth resource parameter, see the dedicated article MCP default resource: when the client skips the audience.

Operability pieces worth a one-line each

Two admin-facing controls landed in the same window and often get configured together with audit review:

• Audit query window caps how far back list and export queries read. Events are not deleted; queries simply stop at the window you set.
• App customers stores an external key and display name for each end-customer company in an environment—your directory for B2B2B, not a second SSO connection.

A limited public GraphQL endpoint (health, eventQueryWindowDays only) lets environment secrets automate health checks without exposing management GraphQL.

Where to start

1. Turn on device intelligence in staging with a policy you can trigger safely (step-up before block).
2. Sign in twice from two browsers; confirm both appear under known devices, then revoke one.
3. Complete an OAuth consent, open the account portal Apps tab, and revoke—the client should fail on the next refresh.
4. For MCP audience binding, follow /blog/mcp-default-resource-oauth-clients.

Changelog entries for each milestone are on /changelog. For Agent Sign-In specifics, start with /docs/agent-sign-in.