Upgrade notes

Newest first. Each change says whether you must act, or only may.

Access tokens are RS256, checked with your app's public keys (act if you check them another way)

Every access token is signed RS256 with your app's own key, which only Identise holds. Check tokens with your app's public keys and nothing else; your API key is only for your backend's calls to Identise.

1. 1

   Verify with your app's public keys

   Point your token check at your app's JWKS, /apps/{appId}/.well-known/jwks.json: examples for ASP.NET Core, Node and Python are in Verifying access tokens. Sessions carry on: the next refresh hands back a token you can check this way.

2. 2

   Take the API key out of services that only check tokens

   They need no secret. Keep the key only on the servers that call Identise.

Stricter checks of your app and its users (act if you see these)

• Every call checks its API key in full: an expired key answers 401 Security.InvalidApiKey, as does a key sent with another app's appId; a suspended app or workspace answers 403 Security.AppSuspended.
• /v1/oauth/logout needs your app's own key, and ends only your app's sessions.
• A suspended user can't refresh or exchange a connection token: 403 User.Suspended. Sign them out when you see it.
• Your app's token lifespans now apply (Token Lifespans); unchanged, they are the 15 minutes and 30 days tokens always had.
• An authenticator code signs in once: reusing one answers 400 Mfa.InvalidCode.
• Asking for a reset or verification email again within a minute answers 200, as for an unknown email, and sends nothing; it was 409 Verification.Cooldown, which told anyone the account exists. Show your own "wait a minute" if you showed that error.
• Use the Google sign-in URL from /v1/oauth/google/url as it is: its state is signed and lasts 10 minutes, and a state built by hand is refused.
• Two requests racing for one thing (one email registered twice at once) answer 409 Database.Duplicate instead of a 500.

Removed: "Sign in with Identise" (act if you used it)

GET /v1/oauth/authorize and the dashboard's Connected Apps page are gone. There is no Identise account to sign in with: your app's users are its own, created and signed in by your backend through the API. If you sent users to /v1/oauth/authorize, sign them in instead with email and password or Google. /v1/oauth/exchange now takes only the connection tokens Google sign-in hands your callback.

Security fixes (act only if you relied on the old behaviour)

• A refresh's retry still gets the same answer for 5 minutes, but only with your app's own API key: a replayed refresh token with any other key gets 401.
• Exchange a connection token once. A second exchange of the same token, even at the same moment, gets 401 (or 409 Database.Conflict) instead of the first one's tokens.
• sso-exchange refuses a suspended user with 403 User.Suspended, as sign-in always has.
• Revoking, rotating or deleting an API key cuts off tokens issued before it wherever your service fetches its JWKS again (see Your app's keys).

Stricter input checks (act if you send odd input)

• Every field is checked before anything runs; a bad one answers 400 with an errors map of every field at fault (Validation errors).
• Passwords are 8 to 256 characters (Password.Invalid); emails must look like emails and fit 255 characters.
• Email templates must contain {{code}} or {{token}}, up to 200,000 characters (HtmlTemplate.Invalid): see Your email, Identise's codes.

Rate limits by plan (act if you call in bursts)

• Each app's limit is now its workspace plan's API limit a minute (1,200 when the plan sets none), counted across every Identise server, with bursts of 5 seconds' worth.
• Calls that hash a password can answer 429 with Retry-After: 1 during a surge. Honour Retry-After on every 429 (Rate limits).

Emails are delivered (no action)

Verification and password-reset emails now go out for real, from your app's name, retried while the mail service is down and never sent twice.