SemAuth 0.10 24 October 2026
A redesigned admin console, administrators you manage yourself, and a broad hardening of how your users sign in. SemAuth 0.10 reached your organization together with SemAuth 0.11.
Highlights
| Feature | What it brings you |
|---|---|
| A redesigned admin console | Find, understand and change your configuration faster — on a laptop or a phone. |
| Manage your own administrators | Add and remove the people who run your organization, without contacting support. |
| Stay signed in for the working day | One sign-in to the console lasts 12 hours. |
| Safer external sign-in | Edit a connected provider, and decide which providers may sign in to existing accounts. |
| Stronger protection for every sign-in | Many attacks on login flows and tokens are now stopped by SemAuth, with nothing for you to configure. |
| Clear usage limits | Predictable ceilings per organization and per realm, so one tenant can never degrade another. |
Check your integration. A few protocol behaviors became stricter. Most applications are unaffected; the checklist at the end lists what to verify.
A redesigned admin console
The console was reorganized around the way administrators actually work:
- Every realm has its own overview, with tabs for its applications, users, identity providers, activity and settings. Everything about one realm is in one place.
- The dashboard shows your organization — its realms and what is happening in them — rather than your own account.
- Grouped navigation and breadcrumbs tell you where you are on deep pages, and the "Create" action sits in each page's header, where you look for it. The menu folds away on a phone.
- Activity is easier to read: times are shown as "5 minutes ago" (hover for the exact time), and the event views can be filtered by event type.
- Destructive actions ask before they act, and every change reports what it did.
- A one-time secret can't be missed. When SemAuth shows a client secret for the only time, the page holds you there until you've copied it.
Why it matters: fewer clicks to the setting you need, fewer accidental changes, and no more re-creating a client because its secret scrolled away unseen.
Manage your own administrators
The Users page lists the people who can sign in to your organization's console. From there you can add an administrator by email address, and deactivate or reactivate one.
- A deactivated administrator loses access on their very next click — not when their sign-in would have expired.
- You can't deactivate your own account or the last active administrator, so your organization can never be locked out of its own console.
Why it matters: onboarding a colleague or off-boarding someone who left is now immediate and in your hands. See Managing users & activity.
Stay signed in for the working day
A console sign-in now lasts 12 hours, renewed silently in the background, where it used to send you back through the login page every hour.
Why it matters: no interruptions mid-task. The 12-hour limit is absolute — a forgotten browser doesn't stay signed in indefinitely — and signing in again from the same browser replaces the old session rather than adding one. Your sessions are listed under Account → Sessions.
Safer external sign-in
Two changes to external identity providers (Google, LinkedIn, or any OIDC provider):
- Edit a connected provider — change its settings or rotate its client secret without deleting and re-adding it.
- Linking to existing accounts is now your decision, per provider. When someone signs in through a provider for the first time and a user with the same email already exists in the realm, SemAuth links the two only if that provider has "Let this provider sign in to existing accounts that match its email" turned on. It is off by default.
Why it matters: automatic linking means trusting the provider to verify email addresses. With a provider you don't control, anyone able to claim your user's address there could otherwise sign in as them. Turn the option on only for a provider that verifies addresses — your own company's identity provider, for example.
Stronger protection for every sign-in
This release closes a long list of ways login flows and tokens can be attacked. None of it needs configuration; each item protects your users, your applications, or both:
| Protection | What it stops |
|---|---|
| A sign-in finishes only in the browser that started it | A captured login link or callback being opened elsewhere to take over an administrator's session. |
| Logout links from other sites ask first | Any web page silently signing your users out with a crafted link. Your applications still log users out directly by sending the ID token. |
| Refresh tokens expire | A refresh token working forever. Unused for 30 days, it expires; regardless of use, a login stays renewable for at most 90 days. Logging out revokes them. |
| Failed client-secret guesses slow down | Brute-forcing a client secret. After repeated wrong secrets the client is paused briefly, doubling each time. |
| Email addresses ignore case | Alice@Example.com and alice@example.com becoming two different users. |
| Authorization responses name their issuer | "Mix-up" attacks against applications that talk to several identity providers (RFC 9207 iss parameter). |
max_age is honored everywhere | An application asking for a recent login and getting an old session instead. |
| Passkeys belong to one account | A passkey registration taking over another user's credential, or reviving a revoked one. |
| Stricter cookies and same-origin checks | Another site, including another organization's console, planting cookies or submitting actions on your users' behalf. |
| Signing keys can be rotated with no downtime | A compromised or ageing key staying in service. Several keys can be published at once, so a rotation never breaks token verification. |
| Personal data kept out of logs | Email addresses, sign-in links and tokens ending up in operational logs. |
The diagram shows the two refresh-token limits: an idle limit of 30 days and an absolute limit of 90 days.
Clear usage limits
Each organization and realm now has fixed ceilings. Going over one is refused with a clear message rather than slowing the service down for everyone:
| Resource | Limit |
|---|---|
| Realms per organization | 10 (disabled realms count; erased ones don't) |
| Realms with a custom domain, per organization | 3 |
| Custom-domain changes per organization | 5 per hour |
| Clients per realm | 100 |
| Applications per realm | 50 |
| External identity providers per realm | 10 |
| APIs per organization | 20 |
Need more? Contact Kovilo support.
Check your integration
| If your application… | Then… |
|---|---|
Calls /introspect | It must authenticate as a confidential client (with a secret or a signed assertion). A client only learns about tokens issued to itself; any other token reports active: false. |
| Registers redirect URIs | Use https, http on loopback only (localhost, 127.0.0.1, [::1]), or a reverse-DNS app scheme such as com.example.app:/callback. Other schemes and URIs with a fragment are refused. See Redirect URI validation. |
Logs users out through /logout | Send id_token_hint with the user's ID token. Without it, SemAuth asks the user to confirm before signing them out. |
| Keeps users signed in with refresh tokens | Expect invalid_grant after 30 days of inactivity or 90 days after the original login, and send the user through sign-in again. |
Verifies tokens against /jwks.json | Pick the key by the token's kid header; don't assume the key set holds a single key. |
| Relied on users being linked across providers by email | Turn on account linking for the providers you trust (see above). |
Uses semauth-cli | Its callback is http://localhost/callback (any port), and the consent screen appears on every run. |