Single sign-on and provisioning
Sign in through Microsoft Entra ID, Okta, OpenID Connect or SAML 2.0, verify your domains, and let SCIM manage joiners, leavers and groups.
Sign in through your own identity provider, and let it decide who may. Memtro speaks OpenID Connect (Microsoft Entra ID, Okta, or any compliant provider) and SAML 2.0, and accepts SCIM 2.0 provisioning so joiners, leavers and group changes arrive from the system that already knows about them.
Everything here is on Dashboard → Organisation → Identity, and an admin or the owner sets it up. Nothing changes for anybody until you make the provider compulsory.
Set it up in the order the page reads
- Add the provider with the details from your end.
- Verify a domain. Until one is verified the provider can sign nobody in.
- Try it. Sign out, type an address at that domain, and the sign-in page offers your provider.
- Make it compulsory, once it works.
- Add provisioning, if you want your directory to manage the member list too.
- Choose what happens to a leaver's memory, which is the one decision Memtro cannot make for you.
Microsoft Entra ID
Register an application in Entra, then:
| In Entra | Value |
|---|---|
| Redirect URI (Web) | https://platform.memtro.com/api/auth/sso/callback |
| Needed from it | Directory (tenant) ID, Application (client) ID, a client secret |
Paste those three into the Entra card on the Identity page. One registration covers everybody at your tenant; Memtro reads the person's address and name and nothing else.
Okta
Create an OIDC Web Application in Okta:
| In Okta | Value |
|---|---|
| Sign-in redirect URI | https://platform.memtro.com/api/auth/sso/callback |
| Grant type | Authorization Code |
| Needed from it | Issuer (usually https://your-org.okta.com/oauth2/default), Client ID, Client secret |
Any other OpenID Connect provider
Give the issuer URL — anything that publishes /.well-known/openid-configuration — with a client ID and secret, and add the same redirect URI at your end. Memtro reads the discovery document to find the rest.
SAML 2.0
For a provider that does SAML rather than OIDC: older Okta applications, ADFS. Create a SAML app at your end with Memtro's details:
| In your identity provider | Value |
|---|---|
| Entity ID / Audience | https://platform.memtro.com/api/auth/sso/saml/metadata |
| Reply URL / ACS | https://platform.memtro.com/api/auth/sso/saml/acs |
| Name ID format | Email address |
| Signing | Sign the response and the assertion. Memtro refuses either one unsigned. |
Then paste the sign-on URL, the identity provider's entity ID and its signing certificate into the SAML card. Memtro's own metadata is served at the entity ID above if your provider prefers to import it.
Starting from your provider's dashboard works too — the Memtro tile in somebody's Okta applications signs them in without them visiting Memtro first.
Verifying a domain
A provider may sign in anybody at a domain it owns, so Memtro will not take your word for which domains those are. Add this TXT record and press Verify:
_memtro.yourdomain.com TXT memtro-verification=…
The exact value is on the Identity page. It is derived from your organisation and does not change, so it is safe to leave in place. DNS can take a few minutes.
A domain routes to one provider across all of Memtro. If yours is already claimed elsewhere, contact support@memtro.com.
Making it compulsory
Until you tick Everybody here signs in this way, your provider is an extra way in and passwords, Google and GitHub all still work. That is the right state while you are testing it, and the wrong state afterwards — because removing somebody in your directory does not take away a password they already have. If you intend your directory to control access, this is the setting that makes that true.
Memtro refuses to make a provider compulsory until it is complete and has a verified domain, because an enforced provider that cannot finish a sign-in would lock out everybody at once.
Two things are unaffected by it:
- API keys. A key is a credential for a program, not a person, and is revoked on its own page or by suspending its owner.
- Somebody suspended. Suspension refuses every door, your provider included.
Who arrives, and as what
With Add people on their first sign-in on, anybody at a verified domain who signs in becomes a member — as a user, or as an admin if you choose that. This is how most organisations run it: the directory decides who exists, and Memtro follows.
Turn it off and a first sign-in is refused unless somebody has already been invited or provisioned.
An assertion can never make somebody an owner: that is the one role that only an existing owner can hand over, on the General page.
Provisioning with SCIM
Create a token on the Identity page and give your provider:
| In Entra or Okta | Value |
|---|---|
| Tenant URL / SCIM base URL | https://platform.memtro.com/scim/v2 |
| Secret token | The token shown once when you create it |
What is supported:
| Operation | What it does in Memtro |
|---|---|
| Create a user | Adds a member. Their address must be at a verified domain. |
Set active: false | Withdraws access: signed out everywhere, keys revoked, connections disabled. Membership, memory and teams untouched. |
Set active: true | Restores access. |
| Update name, external id | Kept against the member. |
| Delete a user | What you chose under When your directory removes somebody. |
| Create or rename a group | Creates or renames a team. |
| Add or remove group members | Changes who is in that team. |
| Delete a group | Deletes the team; its people stay in the organisation. |
A provisioning token takes no seat and cannot read anything: it manages the member list and nothing else. It cannot create accounts at a domain you have not verified.
A pushed group does not carry what the team is allowed to do. Your directory knows who is in Finance; what Finance may read stays with your admins, on the Teams page.
Not supported, and refused rather than half-done: sort, bulk operations, and filters other than attribute eq "value". Fields Memtro does not hold — department, title, manager — are accepted and ignored.
When your directory removes somebody
This is the one thing provisioning cannot decide for you, and it is worth a minute.
A person's personal memory is bound to the organisation. What they alone learned — from their own mailbox, their own conversations — is readable by them and by nobody else, and the moment their membership goes it is readable by nobody at all. So a removal has to say what becomes of it, and after the removal there is no longer anybody who knows what the answer should have been.
A removal arriving from your identity provider has nobody in it to ask. So you choose once, in advance:
| Choice | What happens |
|---|---|
| Withdraw their access and keep everything (the default) | They are signed out and their keys stop working. Everything else stays and comes back if your directory adds them again. Nothing is lost. |
| Hand what only they knew to their team | Their personal memory becomes their team's, readable by its members. |
| Hand what only they knew to the organisation | It becomes the organisation's, readable by everybody here. |
| Erase what only they knew | Deleted, with a receipt. This cannot be undone. |
Shared memory — anything learned from a connected system, a shared conversation or a team's work — is the organisation's either way and is never affected.
The default is deliberate: active: false is what both Entra and Okta send when somebody leaves, and it already does the thing you want. A hard delete is the rarer case.
What is recorded
Every one of these appears in the audit log with who did it: the provider configured or removed, a domain claimed, a token created or revoked, and every member provisioned, suspended, restored or removed. Provisioning actions are recorded against your identity provider rather than against the person signing in at the time.
Troubleshooting
"No identity provider is configured for that address." The domain is not verified against a provider yet. Check the TXT record resolves.
"… asserted an address at a domain this organisation has not verified." The provider sent an address outside your verified domains. Either verify that domain too, or check which attribute your provider is sending as the address.
"That identity provider is missing its application ID or client secret." The card is incomplete. The secret is never shown back, so if you are unsure, paste a fresh one.
Entra's provisioning test fails. Check the token has not been revoked and that the tenant URL ends in /scim/v2.
Somebody cannot sign in with a password any more. That is enforcement working. They should use the provider's button; if they are not in your directory, add them there or turn enforcement off.