With SAML-based single sign-on (SSO), users can access Miro through an identity provider (IdP) of their choice.
Available for: Enterprise, Business plans
Set up by: Company Admins
How SAML SSO works
- When a Miro user tries to log in to Miro using SSO, Miro sends a SAML (Security Assertion Markup Language) request to the identity provider (IdP)
- The identity provider validates the user’s credentials and sends a response back to Miro to confirm the member's identity
- Miro acknowledges the response and grants access, allowing the member to log into their Miro account
What happens after enabling SSO?
Enabling SSO for the first time
The first time you set up SSO, existing users can keep working in Miro without interruption. However, the next time they log out, their session expires, or they try to log in from a new device, they will need to sign in via SSO.
Other login options will be disabled for users, including standard login + password, Google, Facebook, Slack, AppleID and O365.
Idle session timeout
If you have enabled Idle Session Timeout, users are automatically logged out of their Miro profile and will need to authorize via SSO again.
Multiple teams and organizations
If your users have multiple Miro teams or organizations, you can configure them to use the same identity provider (IdP) for authentication.
Who is required to sign in with SSO
SSO sign in is required for active users that are part of your Enterprise subscription and have a domain listed in your SSO settings.
Users accessing Miro from domains not added in your SSO settings are not required to log in with SSO, and should instead log in using the standard login methods.
- Users from a verified domain, who are not part of your Miro Enterprise subscription, need to sign in via single sign-on (SSO) only if just-in-time (JIT) provisioning is enabled. These users will automatically be added to a pre-configured team and will be required to use SSO for login.
- Managed users who belong to a Miro team outside your Enterprise subscription must still use single sign-on (SSO) for authentication. These users will have access to other teams. To restrict access to specific teams, update your domain control settings.
Managing user details
User data is automatically attributed in Miro by your identity provider upon successful login. Some parameters like name and password cannot be changed. Other parameters like department and profile pics are optional.
- Miro Usernames are updated after every successful user authentication. For more information on how to set up Miro usernames, see the advanced SSO settings. If you need to change a user's email address, you can do so only via SCIM. If you do not use SCIM, please reach out to the Support Team.
Domains in SSO settings
💡 To prevent a lockout, create a 'break the glass' user with an email that has a domain outside of the domain listed in the SSO settings, like firstname.lastname@example.org. Otherwise, you can contact support, and they can disable SSO for the whole organization.
Identity providers (IdP)
Use any identity provider of your choice. Below are the most popular identity provider platforms:
How to configure your IdP
💡 If your Enterprise organization would like to add multiple identity providers (IdPs), sign up for our private beta.
1. Go to your identity provider's configuration section and follow the provider's instructions to configure Single Sign-On.
2. Add the following metadata. We recommend skipping any optional fields and leaving any default values as they are.
|HTTP Redirect for SP to IdP
HTTP Post for IdP to SP
The service URL (SP-initiated URL)
Also known as Launch URL, Reply URL, Relying Party SSO Service URL, Target URL, SSO Login URL, Identity Provider Endpoint, etc.
Assertion Consumer Service URL
Also known as Allowed Callback URL, Custom ACS URL, Reply URL
Also known as Identifier, Relying Party Trust Identifier
|Default Relay State
|must be left empty in your configuration
An unsigned SAML Response with a signed Assertion
Identity Provider SAML-response must contain Public key x509 certificate issued by the Identity Provider.
⚠️ Encryption and Single Log Out are not supported.
Any additional fields outside the below are not required. We recommend skipping any optional fields and leaving any default values as they are.
|Required user credential attributes
NameID (equals a user’s email address)
Also known as SAML_Subject, Primary Key, Logon Name, Application username format, etc.
Optional attributes to be sent with the assertion
(updated with every new authentication via SSO, used when present/available)
How to enable SSO in your Miro settings
✏️ Enabling SSO in your settings does not immediately enable SSO for users. SSO login will only be available after your domains have been verified.
2. Toggle on SSO/SAML
2. Toggle on SSO/SAML
⚠️ We strongly recommend working with two windows open: test the login procedure in incognito mode while you keep the settings open in the standard browser window. This way you can easily switch off the SSO authorization in case something is configured incorrectly. If you wish to set up a test instance before enabling SSO on production, please reach out to the Support Team for assistance.
How to configure SSO in your Miro settings
After toggling on the SSO/SAML feature in single sign-on settings, fill in the below fields:
- SAML Sign-in URL (in most cases it opens your Identity Provider's page where your end-users are to enter their credentials)
- Public Key x.509 Certificate (issued by your Identity Provider)
- All domains and subdomains allowed or required (ACME.com or ACME.dev.com) to authenticate via your SAML server
Miro SSO settings
Renewing your SSO/SAML certificate
If your Public Key x.509 Certificate has expired, SSO will continue to work, but it is strongly recommended to renew it in order to continue using Miro securely. Public Key x.509 Certificates ensure the security, privacy, authenticity, and integrity of information shared between your identity provider and Miro.
These certificates are only valid for a period of time which can be specified (and verified) with your identity provider. Please check with your identity provider to verify the expiration date.
There are two steps to this process:
- Renew the certificate with your identity provider. Please check their instructions on how to do this.
- Add the renewed certificate to your Miro SSO configuration.
Adding renewed certificates to Miro
⚠️ We recommend replacing your x.509 certificate during less busy periods in your organization (for example on the weekend or after business hours) to avoid login disruptions.
- Go to your Company settings > Authentication > Single sign-on
- Delete the content inside the Key x.509 Certificate field
- Paste the new key inside this field
- Scroll down and click Save
Renewing an x.509 certificate in Miro
Verifying your SSO domains
Set up by: Company Admins
💡 Domains already verified via Domain Control do not need to be verified again.
After you enter a domain name, you will be required to verify it. Until the domain is added to the domain list in your SSO settings and then verified, SSO will not be available to your users. If a domain is not verified, you will see the note VERIFY EMAIL in your SSO settings.
Non-verified domain in Miro SSO settings
Requirements for successful domain verification
- The person who performs the verification must be a Company Admin. If you're a Company Admin and wish to send the verification email to someone who is not a Company Admin, they can forward the verification email with the confirmation link to you to complete the process.
- The email address used must be real (able to receive the verification email).
- Public domains (e.g. @gmail.com, @outlook.com, etc.) are not allowed.
- The SSO feature must be enabled, and the domain name added in SSO settings.
How to verify your domains
- After adding a domain, a pop-up will open asking you to enter an email address in order to verify the domain. Enter the email address using the same domain you added in your SSO settings to prove that you represent that domain
- Click Send verification
- You will receive the verification email within 15 minutes
- You will need to click the verification link in the email. To complete this step, you must be a Company Admin
- To finish, click the Save button
- Users from the verified domain can now sign in with SSO
SSO domain verification pop-up
💡 If you manage several domains and subdomains (subdomains are recognized as separate names and require separate verification), please first verify at least one domain name and then submit a request to the Support Team with a full list of the domains (must be separated by a comma) so we confirm them at once for you. If you have more than 10 domains, Miro will verify them for you. Organizations with less than 10 domains must verify themselves. Only 3 domains can be verified per organization on the Business Plan.
Optional advanced SSO settings
The optional settings section is used by advanced users who are familiar with SSO configuration.
Just In Time Provisioning for new users
Make it easier for your users to get started with Miro right away, without having to wait for an invitation or going through a lengthy onboarding process. And ensure free teams are not created outside of your managed subscription (requires domain control). SSO is required to enable the Just-in-Time (JIT) provisioning of new users. All users provisioned under JIT are assigned the default license of your subscription:
|Behavior when licenses run out
|Users are not automatically added; JIT feature stops working.
|Enterprise Plan (without Flexible License Program)
|Users provisioned under Free Restricted license
|Enterprise Plan (with Flexible License Program activated)
|Free or Free Restricted License
|Depends on the default license settings
How to enable Just-in-Time provisioning
When you activate Just-in-Time provisioning, it will automatically apply to all new users who register to Miro. However, existing Miro users will still need an invitation to join your plan.
- Go to your SSO settings
- Tick the box Automatically add all newly registered users from the listed domains to your Enterprise account
- Choose a default team for newly registered users from the dropdown
- Click Save
When you list specific domains in your Single Sign-On (SSO) settings, any users who register with those domains will be automatically added to your Enterprise subscription. They will be assigned to the team you have selected in your Just-in-Time (JIT) settings.
Enable Just in Time provisioning feature on the Enterprise integrations page
All newly registered users from the domains that you list in the settings will be automatically added under your EnterpriseUmbrella to this particular team when they sign up with Miro.
⚠️ On the Enterprise plan this team will also be shown in the list of discoverable teams if you enable Team Discoverability.
Setting DisplayName as the default username
By default, Miro will use FirstName + LastName attributes. Alternatively, you can request to use DisplayName instead. In this case, Miro will use DisplayName when it's present in the user's SAML response.
If the DisplayName is not present, but FirstName + LastName are, Miro will use FirstName + LastName. Please get in touch with Miro Support to make DisplayName your preferred SSO Username.
If neither of the three attributes is present in your SAML communication, Miro will show the user's email address as Username
|FirstName + LastName
|DisplayName (if present in the user's SAML request)
|FirstName + LastName (if DisplayName is not present)
|Preferred SSO Username
|DisplayName (contact Miro Support)
|No attributes present
|Email address displayed as Username
If you see something different than expected you may need to authenticate via SSO, or it's possible that the SAML-response does not contain the values needed to update.
Syncing user profile pictures from IdP
⚠️ Generally it's recommended to enable this option if you do not enable SCIM, or your IdP does not support the ProfilePicture attribute (for example, ProfilePicture is not supported by Azure). In other cases, it is recommended to pass ProfilePicture via SCIM with immediate updates.
When this setting is turned on:
- profile picture set at IDP side will be set as profile picture in the user’s Miro profile
- users won’t have the ability to update or remove their profile picture themselves
As with the user name attribute, users will not be able to change their data on the Miro end immediately, but the data sync is not immediate, the IDP side sends the update to Miro only with the user's next SSO authentication (provided that “Sync user profile photos from IDP” setting is still active at that point).
If the profile picture is set in IDP and you wish the attribute to be passed in SAML communication, Miro will expect the following schema:
<saml2:Attribute Name="ProfilePicture" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
SSO with Data Residency
If you make use of Miro's Data Residency support and have a dedicated URL (workspacedomain.miro.com) then you must adjust your identity provider's configuration.
To do this, you will need to add your [ORGANIZATION_ID] to the URL.
You can find your ORGANIZATION_ID from the Miro dashboard by clicking on your Profile in the upper right corner > Settings > it's shown in the URL in the address bar.
|Value under Data Residency
|Assertion Consumer Service URL (aka Allowed Callback URL, Custom ACS URL, Reply URL):
|Entity ID (Identifier, Relying Party Trust Identifier): https://miro.com/
Setting up Multi-factor authentication (2FA) for users outside SSO
Two-factor authentication (2FA) provides an added layer of security. With 2FA, users are required to complete an extra step during login to verify their identity. This additional measure ensures that only authorized individuals can access your subscription.
Learn more in our Two-factor authentication admin guide.
Possible issues and how to resolve them
If one or all of your users encounter an error when trying to sign into Miro, please check this list of common errors and how to resolve them.