SemAuth 0.11 24 October 2026
This release is about privacy. You can now permanently erase a person's data when they ask for it, correct a user's email address without losing their account, and give your APIs the sign-in details they need without an extra round trip. Your tokens also now carry only the personal data your users agreed to share.
Highlights
| Feature | What it brings you |
|---|---|
| Erase personal data on request | Answer a right-to-erasure request in one step, from the console or the Admin API, and keep a complete audit history. |
| Change a user's email address | Fix a typo or follow a user to a new address while keeping their account, passkeys and linked logins. |
| Richer access tokens for your APIs | Your APIs learn who signed in, when, and how strongly, straight from the token. |
| Tokens share only what was consented to | An email address reaches an application only when the user granted the email scope. |
| Recognizable client secrets | New client secrets carry a fixed prefix, so a leaked one is easy to spot. |
Erase personal data on request
When someone asks you to delete their data, you now have a dedicated action for it. It removes the person from the realm entirely: their account, their sign-in methods (passkeys, linked Google or LinkedIn identities) and their active sessions. Every record of them in your activity history becomes permanently unreadable.
Why it matters
- Compliance in one step. Data-protection rules such as the GDPR give people the right to have their personal data erased. Answering that request used to mean contacting support. Now an administrator does it in a few seconds and gets a dated confirmation.
- Your audit trail stays intact. Erasure doesn't punch holes in your history. The Activity view still shows that something happened and when, so your security and compliance reviews keep working. Only the personal details are gone: an erased address shows as erased.
- Erased means erased. Erasure is permanent and can't be undone, by you or by Kovilo. The data can't be recovered or restored afterwards.
Three ways to erase
| What | Where in the console | When to use it |
|---|---|---|
| A user | Realm → Users → Erase on the user's row | A person with an account in the realm asks to be forgotten. |
| An email address | Realm → Users → Erase an address | Someone who started a sign-in but never finished it. They have no account to pick from the list, but the realm still holds their address. |
| A whole realm | Realm → Settings → Erase realm | You're retiring a realm and want the data of all of its users gone. |
The Users page (your organization's administrators) has the same Erase action for a former administrator.
Built-in safeguards. Because erasure can't be undone, the console asks you to type the person's email address (or the realm's issuer ID) before it goes ahead. A realm can be erased only after it has been disabled, and an erased realm can never be re-enabled. You can't erase your own administrator account or the last active administrator of your organization, so you can never lock yourself out.
An erased realm stops counting toward your organization's realm limit. If it had a custom domain, the domain is released and you can assign it to another realm.
From the Admin API
Erasure is also available through the Admin API, so you can connect it to your own data-request process:
| Method | Path | Purpose |
|---|---|---|
| POST | /v1/realms/{issuer_id}/users/{user_id}/erasure | Erase a user. |
| POST | /v1/realms/{issuer_id}/erasures | Erase an email address (body { "email": "…" }). |
| POST | /v1/realms/{issuer_id}/erasure | Erase a disabled realm. |
Each call returns a receipt with the date of the erasure. For a person, the receipt also includes the account that was removed, if there was one, and how many activity records mentioned them. For a realm, it includes how many user accounts were removed. File the receipt with the request it answers.
Better protection for the personal data you keep
To make erasure possible, SemAuth now protects each person's data in your activity history on its own. Their email address, the network address they connected from and the browser they used are locked so that only that person's data can be unlocked, and erasing them destroys it for good. Two related changes:
- The Emails log keeps the recipient, the subject and the delivery status of each message, but no longer the message itself. A sign-in link that was emailed to a user can't be read again from your history.
- Activity that isn't tied to a particular person records only a shortened network address, enough to see where a request came from but not who sent it.
Change a user's email address
On a realm's Users page, each user now has a Change email action. Enter the new address and the account moves to it.
Why it matters
- Users keep everything. People change jobs, rename their mailbox, or mistype their address the first time. Until now the only fix was a new account, which meant losing their passkeys, their linked Google or LinkedIn identities, and the user ID your applications know them by. The account now stays the same, and only the address changes.
- No account takeover by typo. The new address starts out as unverified. The user proves they own it the next time they sign in with a magic link. If the address already belongs to another account in the realm, the change is refused.
- Your applications stay in sync. Because the user ID (
sub) never changes, your applications keep recognizing the user. The new address shows up in their tokens from the next sign-in.
Good to know. Changing an address doesn't sign the user out of the sessions they already have. To end them, deactivate the user. Administrators' addresses aren't changed from this page.
Richer access tokens for your APIs
When a user signs in to an application that calls one of your APIs (an MCP server, for example), the access token the API receives now says more about that sign-in:
| Claim | What your API learns |
|---|---|
email / email_verified | The user's address and whether it's verified, when the user granted the email scope. |
auth_time | When the user last actually signed in. |
acr | How strong that sign-in was: aal1, aal2 or aal3. |
amr | Which methods were used, such as a passkey or a magic link. |
Why it matters
- Security decisions where they belong. Your API can refuse a sensitive operation unless the user
signed in with a passkey (
acr = aal3), or unless they did so in the last few minutes. It doesn't need to trust the calling application to have checked. See Assurance levels & step-up. - One less round trip. An API that needs the user's address reads it from the token instead of
calling
/userinfoon every request.
Tokens share only what was consented to
SemAuth now follows the OpenID Connect rules for which personal data goes into a token:
- The user's email address goes into ID tokens only when the application requested the
emailscope and the user granted it. This is the same rule/userinfoalready followed. - An ID token is issued only when the application requested the
openidscope.
Why it matters: a user's address now reaches only the applications they agreed to share it with. That limits how far personal data spreads, keeps what your users see on the consent screen accurate, and makes your own data-protection documentation simpler.
Check your integration. If one of your applications reads email from the
ID token, make sure it requests the email scope, for example
scope=openid email profile. Applications that already request it are unaffected. To identify a user,
always rely on sub: it's stable for the life of the account, while an email address can now change.
Recognizable client secrets
Client secrets that SemAuth generates, for your confidential clients and for
Admin API credentials, now start with sa_cs_.
Why it matters: a secret that ends up somewhere it shouldn't, such as a commit, a log file or a support ticket, can now be found by searching for its prefix. You can also teach your own secret-scanning tools to flag it. When you rotate an Admin API credential's secret, the old one stops working immediately.