What’s new

Each entry says what changed and links to where it is explained. Changes reach the shared platform first; the libraries are versioned on their own, and each entry names the version that brought a change.

19 October 2026

• Error screens that match the sign-in. A client’s error screen follows the arrangement chosen for its sign-in (panel beside, centered or cover), with the same brand panel and the error in the card where the form would be. From there, Back to sign in resumes the sign-in where it stopped, and a second button leads back to the application. A refused authorization request, such as an unregistered return address (redirect_uri), is now explained in the screen’s language. See branding.
• GitHub sign-in reaches the existing account. When a GitHub account makes its e-mail public, Authio now checks that address’s verification with GitHub’s e-mails API. With Link on verified email and the trust setting on, the person signs into the realm’s account that already has that e-mail, instead of the sign-in being refused as a duplicate. See account linking.
• Recognizable providers in sign-in options. On a client’s Sign-in options tab, when viewing and when editing, each provider shows its own brand mark (Google, Microsoft, GitHub, Apple), and editing shows each one’s position beside it. See add a provider.
• Compact inherited claims. In the Permissions step of editing a user, the claims that come from roles are grouped by type, with their values side by side, instead of one row per pair. See assign roles.

18 October 2026

• Screens that load in place. While their data is on its way, the console’s screens already draw the shape they are about to take: every section of the dashboard, the lists, the tabs of a record and the steps of an edit. Nothing pushes what you are reading when the figures land, and a value that is still loading no longer shows as a zero, an empty state or a raw identifier. See the dashboard.
• Human check at sign-in. The hosted login (the password step and the request for a code by e-mail), Forgot password? and creating an account in the console ask for a Cloudflare Turnstile check when the deployment has its keys. At sign-in it is almost always invisible, and if Cloudflare is down the sign-in stays protected by attack protection; on Forgot password? and when creating an account, the screen refuses without Cloudflare’s answer. See human check.

17 October 2026

• Self sign-up. A client can let people create their own account from its sign-in screen: anybody, or only addresses at the domains you list. The account is confirmed by e-mail before it opens, the screen never says whether an address already has one, and a Cloudflare Turnstile check holds scripts back. See self sign-up.
• Sign in with a code by e-mail. A client can let people in without a password: they type their name and the 6-digit code mailed to the account, which lasts 10 minutes and opens one sign-in. It can sit beside the password, and an authenticator app, a phone approval or a passkey can follow it. See sign in with a code by e-mail.
• Your data, in the account portal. People download a copy of everything the realm keeps about them as a JSON file and, when the realm turns it on, delete their own account after a recent sign-in. See your data.
• Activity in the account portal. The Activity tab lists the person’s own sign-ins, read by the person and the realm the session proves. See the account pages.

16 October 2026

• Libraries 0.9.0. The Node.js packages in @hyper.authio and the .NET packages accept an access token only with the at+jwt type of RFC 9068, and add a backend for single-page apps (BFF) in Express and ASP.NET Core that keeps the tokens on the server. See Node.js and .NET.
• Next.js provider 4.1.0. @hyper.authio/provider-nextauth decrypts encrypted tokens on its own, on Auth.js v5 and NextAuth v4. See Next.js and token encryption.
• MCP 0.5.0. @hyper.authio/mcp and Authio.Mcp.AspNetCore take the client’s settings by their protocol names (tokenEndpointAuthMethod, accessTokenSignedResponseAlg), verify HS-signed tokens with the client secret, and no longer assume a scope or introspection the server did not state. See upgrading from 0.3.
• A connected console. Screens that name a realm, client, user or key link to it, and lists open grouped by what matters most about their records, such as clients by posture. See working with records.
• Integration guides in the console. The guides of Clients and of each realm walk through every library step by step, and each client’s Guide builds its recipes from the client’s own settings, now also for a BFF, a .NET worker and an MCP server.
• Dedicated environments. The API of a dedicated environment catches up with the shared platform, including the at+jwt access tokens the 0.9 libraries require. See Dedicated environment.

15 October 2026

• All realms, everywhere. With All realms in the realm selector, each list reads and counts its records across every realm you administer, and the dashboard, support and notifications follow the realm you pick. See the console tour.

14 October 2026

• Dynamic client registration (RFC 7591). A realm can let clients register themselves, off by default, for MCP clients that can neither be registered by you nor publish a metadata document. See MCP and the registration endpoint.
• Access tokens typed `at+jwt`. Access tokens carry typ at+jwt in their header, as RFC 9068 asks, so an ID or refresh token signed by the same keys is never taken for one. See validating tokens.
• Base fee, included quota and overage. Each plan is a fixed monthly fee that includes monthly active users and machine tokens, with every unit past the quota billed at the plan’s overage price. See plans and billing.
• Webhook signing secrets. Rotating a secret can keep the previous one working for a while, and a realm’s endpoints also receive the user_* events of every person of the realm. See rotating the signing secret and client and realm endpoints.
• Notifications in your language. Each notification is shown in the language of whoever reads it, its e-mail goes out in the account owner’s, and the notification webhook adds key and arguments. See notifications and notification webhooks.
• Error codes. Every validation rule of the admin API answers with an errorCode of its own. See error codes.

13 October 2026

• Authenticator app as a sign-in step. Your users can answer a second factor with a code from Google Authenticator, Microsoft Authenticator or any TOTP app, with recovery codes. See authenticator app.
• Scopes that require assignment. A scope can be limited to the people and groups it was assigned to, the way a role is. See scopes that require assignment.
• Two signing settings. The access token has a signing algorithm of its own, apart from the ID token’s, and HS256, HS384 and HS512 are signed with the client secret, as OpenID Connect asks. See token signing.
• `RSA-OAEP-256` by default. Encrypted tokens use RSA-OAEP-256 as the key encryption algorithm unless the client chooses another. See token encryption.
• One response envelope. Every answer of the admin API, success or error, comes in the same envelope. See the admin API.

12 October 2026

• Support portal. Open a ticket about anything the console shows, a failed request included, and follow the answer in the console. See support.
• A trial on the plan you chose. The free trial is a real subscription to the plan picked at sign-up, with no card asked for, and each plan sets its own trial length. See the free trial.
• Introspection returns every claim. An active token’s introspection carries every claim the access token does, the person’s name and e-mail and claim mapper outputs included. See introspection.

11 October 2026

• Attack protection. Every realm detects credential stuffing, password spraying, brute force, push bombing and recovery abuse and answers them by itself, and an AI analyst reads each incident on plans with the AI advisor. See attack protection.
• Sign in with a username, an e-mail or either. A realm decides what its people type to sign in. See usernames.
• A reset code in the e-mail. The password reset e-mail also carries a 6-digit code that continues the reset in the tab where it was asked for. See password reset.
• No welcome credit. New accounts start on the free trial and receive no credit. See welcome credit.

9 October 2026

• Tokens encrypted to the client’s own key. A client can have its tokens encrypted with a key of its own. See token encryption.
• UserInfo as a JWT. The UserInfo endpoint can answer with a signed or encrypted JWT when the client registers it. See UserInfo as a JWT.

Next steps