Changelog

Every change that an integration can observe — new endpoints and scopes, changed responses, and corrected behaviour — with the date it landed and the environments that have it.

Check the availability column before you build. Changes reach dev first and a given environment only at its next deployment. An entry marked Development is not yet present on the production base URL. See Environments & base URLs for what each one currently serves.

Additive by default. New fields are added to existing responses rather than replacing them, so ignoring a field you do not use is always safe. Anything that could break an existing integration is called out explicitly in its entry.

2026-08-12 — Bounded fleet enrolment and Phase 4 write errors

Fleet enrolment now rejects database conflicts with stable codes, preserves retry accounting, and applies pre-database abuse controls plus operator-bounded tenant capacity.

Changed

Change	What it means for you	Availability
Anonymous redemption and installation capacity are genuinely bounded	`/api/v1/enrolment/redeem` now passes a two-bucket limiter before opening a database transaction. Tenant limit changes cannot exceed their operator-approved maximum; platform exceptions use a separate permission boundary and durable audit event.	Development

Fixed

Change	What it means for you	Availability
Phase 4 constraint failures now have actionable codes	Duplicate installation keys, concurrent external-principal claims, duplicate issuers, and invalid tenant-scoped app/workspace/identity references no longer collapse into an internal error. Values are additive and permanent; integrations should retain a default branch for future codes.	Development

2026-08-12 — Machine-readable login failures and consistent native logout

Direct and hosted login now share stable actionable codes, and native apps can use the same loopback redirect policy when signing out as when signing in.

Added

Change	What it means for you	Availability
Local back-channel logout development guidance	Use a temporary public HTTPS tunnel to a local receiver. Local, private, non-HTTPS, and redirecting targets stay refused in every environment so production SSRF protection and development behavior cannot diverge.	Development

Changed

Change	What it means for you	Availability
Credential and rate-limit responses now emit stable codes	Direct problem responses now emit `invalid_credentials` for rejected login proofs and `rate_limited` for general limits. Hosted OAuth responses emit the same values in `error_code`; `login_temporarily_locked` remains unchanged. These fields are additive where no code was emitted before. Integrations with a`default:` branch should add explicit cases if they want tailored user messages or retry behavior. Wrong passwords and unknown identities remain byte-identical.	Development

Fixed

Change	What it means for you	Availability
Post-logout loopback redirects match authorization redirects	Native clients may register HTTP post-logout redirects on `localhost`, `127.0.0.1`, or `[::1]`, and may use a different runtime port. Scheme, host, path, and query still match; every non-loopback target remains exact HTTPS.	Development
Trusted-device alerts are branded and now name the device, time, and a way to act	The trusted-device notification your users receive previously arrived unbranded and told them to remove the device without saying where. It now carries the standard authreads layout and states the device, platform, IP address and time, with a link to the hosted account-security page. The link is built from your configured hosted-login origin, so it points at the page your users already use. Every authreads email now also sends a plain-text alternative alongside the HTML part, which improves deliverability for one-time-code mail. A tenant administrator can still disable the trusted-device alert under Authentication → Security policy; doing so does not suppress the `trusted_device.created` audit record or the device inventory entry.	Development
Set-password emails name the right sender, reason, and expiry	One template served two unrelated situations, so a user who requested a first password through forgot-password was told “You have been invited” and warned to be suspicious of a message they had just asked for. These are now separate emails. The self-service one states that the reader asked for it; the invitation one is subject-lined `<your company name> invited you — set your password` and names your company in the body, because your users were invited to your application and do not recognize authreads. Invitation and onboarding emails also stated the wrong lifetime: they promised one hour for links that are valid for seven days, so recipients abandoned working links and asked for re-sends they did not need. Every link email now states the lifetime its token is actually minted with. No token lifetime changed — only the wording, which was wrong.	Development

2026-08-11 — Reliable OIDC session termination

Relying parties can now receive a signed, durable notification when an Authreads OIDC session is revoked or reaches its absolute expiry.

Added

Change	What it means for you	Availability
OpenID Connect Back-Channel Logout 1.0	Register an HTTPS `backchannel_logout_uri` on your OIDC client and implement the standard `logout_token`receiver. Authreads retries temporary delivery failures without delaying the user's logout, and the client settings show repeated failures. Verify the token signature, issuer, audience, lifetime and logout event; reject a token containing `nonce`; deduplicate on `jti`; then end the session identified by `sid`. See Sign in with Authreads.	Development

Changed

Change	What it means for you	Availability
Hosted lockouts include a stable extension code	Hosted OAuth lockouts still use the standards-compatible `temporarily_unavailable`error, and now also include `error_code: login_temporarily_locked`. Branch on that extension instead of matching human-readable prose.	Development

Fixed

Change	What it means for you	Availability
Idle-timeout scope is documented explicitly	Authreads enforces idle timeout on hosted browser sessions and direct/BFF integrations that present `x-session-activity`. A hosted OIDC relying party must enforce human inactivity in its own session; read `idle_timeout_minutes` from the signed `https://authreads.com/claims/session_policy` ID-token claim. Back-channel logout carries Authreads revocation and absolute-expiry decisions, but does not turn a server-side token operation into proof of user activity.	Development

2026-08-11 — Live policy inheritance and honest login errors

A tenant's security policy now actually inherits platform-default changes, and a locked-out login is no longer indistinguishable from an expired OAuth grant.

Fixed

Change	What it means for you	Availability
Tenant security policy inherits platform-default changes again	A tenant's policy row previously stored a full copy of every platform default, not only the fields it deliberately chose, so a platform-default change never reached any tenant — password, MFA, lockout, and trusted-device enforcement were evaluated and then silently discarded. Policy rows are now sparse: only deliberate overrides are stored, and every other field resolves against the live platform default on each request. Deliberate tenant customizations are unaffected. See Authentication settings.	Development
Login failures return honest, distinguishable errors	Hosted login failures previously collapsed almost everything into OAuth's generic `invalid_grant`/ "grant invalid, expired, or already used". A temporary lockout is now its own explicit response on both planes, with `Retry-After`. If you pattern-matched on the old generic grant-error text to detect a lockout, that match will stop firing — branch on `code` (direct) or the documented OAuth error instead. See Errors & rate limits.	Development
New-trusted-device notification email now actually sends	The notification introduced below never delivered in any environment where the database role is not a superuser — dev or production — because the throttle record backing it was written on the admin connection, which the row's own tenant-isolation policy silently rejects. It now writes on the correct tenant-scoped connection. If you depend on this email, re-verify delivery; nothing about the API contract changed.	Development

2026-08-11 — Account security for tenant backends

Self-service session and trusted-device management became reachable from a tenant's own backend, not only from our hosted login pages.

Added

Change	What it means for you	Availability
Seven account-security endpoints on the tenant BFF surface	Under `/api/v1/auth/users/{user_id}/apps/{app_id}/account-security/`: list and revoke sessions, list and revoke trusted devices, a combined revoke-others-and-devices, and a policy read. Previously these existed only behind the hosted OIDC token shape, which a backend-for-frontend integration cannot mint. See Sessions & tokens.	Development
account-security:read and account-security:manage scopes	Both are opt-in and granted to no existing credential automatically. `account-security:manage`can end another person's access, so it is marked dangerous when granting. See API & credentials.	Development
Per-tenant control of the new trusted-device email	A tenant that would rather send its own branded notification can turn ours off. Delivery is enabled by default. Disabling delivery never suppresses the audit record — the security evidence is written in the same transaction that creates the device.	Development
Trusted devices on the hosted login	The one-time-code step accepts `remember_device`, and the response returns the window your tenant actually resolved to — so your UI states the real number of days rather than mirroring a constant. Tenants choose any value up to a 90-day platform ceiling.	Development
Session idle timeout	Authreads-hosted browser sessions now end after a period of real pointer or keyboard inactivity as well as at their absolute expiry. Direct/BFF clients enforce the same boundary with the signed activity contract — `GET /api/v1/auth/me` now requires the current `x-session-activity` token on every call and fails `401` without it; hosted OIDC relying parties enforce the resolved setting in their own browser session. Tenant-configurable from 15 minutes to 365 days; the platform default is 30 minutes. See Sessions & tokens.	Development

Changed

Change	What it means for you	Availability
Session exchange returns session policy and activity state	`POST /api/v1/auth/session/exchange` now also returns `session_policy` (including the resolved idle timeout) and `session_activity_token`. The exchange response itself is additive — existing fields are unchanged — but a Direct/BFF client that discards `session_activity_token` will find its `GET /me` calls start failing once this reaches its environment, because that endpoint now requires it.	Development
RP-initiated logout no longer requires id_token_hint	`GET /oauth/logout` now accepts `client_id` as an alternative, matching OpenID Connect RP-Initiated Logout 1.0, which marks `id_token_hint` RECOMMENDED rather than REQUIRED. At least one of the two is still required, because the client identity is what validates your `post_logout_redirect_uri`. Relying parties that discard the ID token after login can now end the session properly instead of receiving a 400.	Development

Fixed

Change	What it means for you	Availability
Logout could leave the single-sign-on cookie alive	The session cookie was cleared with attributes that did not always match how it was written, so in some deployments the browser kept it and the next sign-in skipped authentication entirely. The deletion now mirrors the write in every configuration.	Development

What is not listed here

Internal refactoring, test coverage, administrative console work and documentation edits are deliberately left out, however large. This page exists so you can tell at a glance whether something you integrate against has moved — a list of everything would defeat that.

If a change you depend on is missing, it is an omission rather than a policy. Tell us and we will add it.