On this page
Set up your organization
Tell us about the organization this workspace represents.
Step 1 of 2
The issuer name identifies your organization as the party that created and signed records on Invoance.
Already have an account? Sign in
What shipped
From today the Invoance sign-in page and the sign-up page both carry a Continue with Microsoft button. If your organisation runs on Microsoft 365, that button signs you in with the account you already use, or creates your Invoance workspace from it, without a new password to choose, store or forget.
It works with work and school accounts from any Microsoft Entra ID tenant. Personal Microsoft accounts such as outlook.com or hotmail.com are not accepted, which is deliberate: Invoance workspaces belong to organisations, and the value of the integration comes from the fact that your directory, not a form, says who you are.
Nothing changes for teams that sign in with a password. The password path, two-factor authentication and backup codes all stay exactly as they were. Microsoft is an additional door, with the same locks on it.
Signing up in one click
Click Sign up with Microsoft, pick your work account on Microsoft's own prompt, and you land back on Invoance with your name and email already filled in. The form reads "Signing up with Microsoft as you@company.com". You name your organisation, confirm the issuer name that will appear on your signed records, enter your primary domain, and you are in the dashboard.
Two things are different from a password sign-up. There is no email verification link to wait for, because the address came from your tenant rather than from a text box. And there is no password on the account at all. If you later want one, for example as a recovery path, Settings offers a Set password link that goes through the normal reset flow.
The pending sign-up is held for fifteen minutes. If you close the tab, start again from the button.
Signing in, and connecting an existing account
For a returning user, Continue with Microsoft looks up the account by the identity your directory presents and issues a session. If the account has two-factor turned on, the authenticator prompt appears next, exactly as it does after a password.
If you already have an Invoance account with a password and the Microsoft account carries the same email, Invoance does not silently merge the two. It asks you to sign in with your password once, then connect Microsoft from Settings. After that, either door opens the same account. The reasoning is in the next section: an email match is a hint, not proof, and the only person who should be allowed to join a Microsoft identity to an existing account is someone who can already open that account.
Connected accounts live in Settings under Security. You can see when Microsoft is connected, and disconnect it, as long as the account still has a password to fall back on. An account with Microsoft as its only credential cannot remove it, because that would lock you out.
Password
No password set. You sign in with Microsoft. Set one to also sign in with email and password.
Microsoft
Connected. You can sign in with your Microsoft work account.
Set a password before disconnecting, so you keep a way to sign in.
Accounts match on tenant and object id, never on email
This is the decision that matters most, and it is the one most integrations get wrong.
When Microsoft signs you in, the ID token carries a tenant id, which identifies your organisation's directory, and an object id, which identifies you inside it. Together they are stable: they do not change when your name changes, when your email alias changes, or when an admin edits your profile. Invoance stores that pair and uses it, and only it, to find your account on every later sign-in.
The token also carries an email. In Entra ID that field is editable by a tenant admin, and it is not required to be an address the tenant owns. An admin of any tenant can create a user whose email says alice@yourcompany.com. If an application matched accounts by email, that user could sign into Alice's account at any service that accepted Microsoft logins. This is a known class of attack, and the defence is simple: never pick an account by the email claim.
Invoance goes one step further. The email claim is accepted as a verified address only when the token also says the tenant has proven it owns that domain. Without that proof, the sign-in falls back to the account's principal name, which is bound to a domain the tenant has verified. The email is then used for exactly one purpose: to notice that a password account with the same address already exists, so we can ask for the password instead of merging.
Inside the Microsoft ID token
OIDC id_token · payload, abridgedWith the signature against Microsoft's published keys: the issuer must name the token's own tenant, the audience must be Invoance, the nonce must match. Any failure ends the sign-in before an account is looked up.
Your directory, and you inside it. The only key used to find your Invoance account. Stable when your name or email alias changes.
Email counts as verified only when xms_edov is true; otherwise the sign-in name is used. Never used to choose an account, only to spot an existing password account.
Two-factor still guards every door
It is tempting to treat a Microsoft sign-in as already two-factor. Many tenants enforce MFA, after all. We chose not to assume it.
A standard Microsoft ID token does not say whether multi-factor authentication happened during that sign-in. Unless the application specifically asks for the authentication methods claim and the tenant agrees to send it, the token is silent on the question. Treating silence as "yes" would mean that an account protected by an authenticator app could be opened by anyone who obtained a Microsoft session for that user, with no second step on our side.
So if you have two-factor on your Invoance account, you will see the authenticator prompt after a Microsoft sign-in, exactly as after a password. Two-factor that guards one door out of several is not two-factor. The code path that issues sessions is shared between the password, authenticator, backup code and Microsoft flows, so there is one place where that rule lives, rather than four places that could drift apart.
A later refinement may honour the authentication methods claim when a tenant sends it, so that an MFA-enforced tenant is not asked twice. That will be an explicit setting an administrator turns on, not a default.
What happens under the hood
The flow is standard OpenID Connect with the authorization code grant and PKCE, straight against Microsoft Entra ID. There is no third-party identity vendor in the path.
Clicking the button sends you to Microsoft with a one-time state value and a nonce that Invoance has stored for ten minutes. Microsoft authenticates you on its own pages, so your Microsoft password never touches Invoance, and returns a short-lived code. The API exchanges the code for an ID token and verifies it: the signature against Microsoft's published signing keys, the issuer against the tenant id inside the token, the audience against our application id, and the nonce against the one we stored. Only after all four pass does the tenant and object id pair get looked up.
The only permissions requested are the ones needed to sign you in: your identity and your email address. Invoance asks for nothing from Microsoft Graph and reads nothing from your mailbox, calendar or files. The consent screen your users see is correspondingly short.
How Continue with Microsoft works
OpenID Connect · code flow + PKCECarries the hand-off
Takes you to Microsoft and brings back a one-time code. The ID token never passes through it.
- your Microsoft password
- your MFA approval
Holds for 10 minutes
A state value, a nonce and a PKCE verifier, created when you click and used once.
- state matches
- signature, Microsoft keys
- issuer is the token tenant
- audience is Invoance
- nonce matches
Two-factor, then session
Signs you in
Your organisation’s own rules apply here: password, MFA and conditional access.
- who you are: tid, oid
- your name and email
- nothing from mail or files
- 01Continue with MicrosoftBrowser to Invoance
- 02Redirect to MicrosoftInvoance to browser
- 03Sign in at MicrosoftBrowser to Microsoft
- 04One-time codeMicrosoft to browser
- 05Code to InvoanceBrowser to Invoance
- 06Code + PKCE verifierInvoance to Microsoft
- 07Signed ID tokenMicrosoft to Invoance
For IT administrators
Invoance is registered as a multi-tenant application, so users from any organisation can sign in with no setup on your side. Your tenant's conditional access and MFA policies apply at Microsoft's end as they would for any other application, and Invoance's own two-factor applies on top.
If you would rather have every member of your Invoance workspace come from your tenant, we can pin the workspace to your tenant id. Once pinned, a user from your directory who signs in with Microsoft and has no Invoance account yet joins the workspace as a member instead of being offered a new sign-up. Ask us and we will set it; there is no self-service control for it yet.
Revoking access works the way you would expect. Disabling the user in Entra ID stops new Microsoft sign-ins immediately, because Microsoft will no longer issue a token for them. Existing Invoance sessions can be ended from the sessions list in Settings or by a workspace owner.
What is not there yet
Teammate invitations still create a password account first; the invitee can connect Microsoft from Settings afterwards. Domain-based routing, where typing an email address sends you to the right identity provider automatically, is not built. Sign-in through other providers over SAML is not built either, and will not be until a customer needs it.
Those are the gaps as of today. Everything above is live at app.invoance.com.