Articles on: Settings & configurations

Securing domain name with Microsoft SSO

Maglr offers the option to secure access with Single Sign-On (SSO, available with an Enterprise license). SSO can protect both the Maglr dashboard (for editors and designers) and a published domain (so publications shared under that domain are protected and not visible to search engines). Access to a domain can also be secured with a manual password or a secret link.


Where SSO Applies — Dashboard and Published Domains

The same Microsoft SSO connection can be used in two ways, and the setup below applies to both:


  • Dashboard access — let editors and designers in your organization sign in to the Maglr dashboard with their Microsoft account.
  • Published domains — protect a domain such as internal.companyname.com so only authenticated, authorized users can view its publications.


Example: Internal Publications for Employees

Consider publications intended for internal use only. If your organization uses “Microsoft 365 / Microsoft Entra ID (formerly Azure AD),” the existing Microsoft authentication can be ideal for securing a domain like internal.companyname.com. While we use Microsoft as an example due to its widespread use in organizations, similar integrations can be set up with other identity providers such as Google or Okta.


Which Protocol Does Maglr Use?

Maglr's SSO is built on the OpenID Connect (OIDC) protocol, layered on top of OAuth 2.0 — it does not use SAML. Authentication runs against the Microsoft identity platform (v2.0 endpoints). After sign-in, Maglr receives a signed token from Microsoft and reads the information it needs to apply your access filter. Because Maglr is provided as a shared, pre-registered Enterprise App, your organization does not need to create its own app registration, redirect URIs, or client secret — at most a one-time admin consent is required.


In short: the user's identity (the login itself) is proven by the OIDC token Microsoft returns, and that same token also carries the profile and group information used to decide whether access is granted.


How Does SSO Work?


  • Accessing a Secured Resource:

When a user opens a secured domain (e.g., internal.companyname.com) or signs in to the dashboard, they are redirected to Microsoft’s login page.


  • Authentication with Microsoft:

If the user is not already logged into Microsoft, they will need to log in.


  • Consent to Connect with Maglr:

The user will be prompted to consent to link their account with the Maglr app. This allows Maglr to read basic profile information (such as email address) — never the user's password or credentials. (Organizations can preconfigure this consent across the organization via Microsoft Entra settings if they don’t want to leave this decision to individual users.)


  • Verification and Filtering:

After logging in and granting consent, the user is redirected back to Maglr. Based on the configured filter (e.g., email domain or group ID), Maglr determines whether the user is allowed access.


  • Access Granted:

If the user meets the filter criteria, they are granted access to the domain or dashboard.


  • Subsequent Access:

If the user returns later (and is still logged into Microsoft), they are directly redirected without seeing the authentication layer again—unless they have logged out.




Maglr App in Microsoft Entra

The Maglr SSO protection operates via an intermediary Enterprise App (a single, shared multi-tenant application), which can be found in the Microsoft Entra dashboard once consent has been granted. By default, the app requests user.read permissions.


  • Name: Maglr
  • Application ID: 6a93cafe-ced9-4730-9c36-2ae21c39ea07
  • Object ID: db5e6f6d-6318-48b5-b174-8d6b6bf11fbe


Delegated Permissions

To simplify the consent process for employees, organizations can pre-approve permissions organization-wide. In Microsoft Entra -> Applications -> Enterprise Applications -> Maglr -> Permissions, these permissions can be managed.


The user.read Profile Permission

The following result is an example of the user.read profile information Maglr receives from Microsoft — minimal company information that lets us grant access on an e-mail (domain) level.


{
  "id": "XXXXXXX-9ac9-4d7a-8c19-XXXXXXXX",
  "mail": "berry@maglr.com",
  "surname": "van Elk",
  "jobTitle": "CEO",
  "givenName": "Berry",
  "department": "Digital Communication",
  "employeeId": "12345",
  "displayName": "van Elk, Berry",
  "mobilePhone": null,
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(id,displayName,businessPhones,givenName,jobTitle,department,mail,mobilePhone,officeLocation,preferredLanguage,surname,userPrincipalName,employeeId)/$entity",
  "businessPhones": [],
  "officeLocation": "Breda",
  "preferredLanguage": null,
  "userPrincipalName": "berry@maglr.com"
}


Passing Group Membership via the Token (Groups Assigned to the Application)

For group-based access — granting access based on which security group a user belongs to — Maglr reads the user's group membership directly from the OIDC token that Microsoft returns at sign-in. Maglr does not query the Microsoft directory for groups, so no broad directory permissions (such as Group.Read.All or Directory.Read.All) are required.


To enable this, your IT administrator configures Microsoft Entra so that the relevant groups are included in the token. Only the groups that are explicitly assigned to the Maglr application are sent — never your full directory — so your organization stays in complete control of which groups Maglr can see.


How to set this up in Microsoft Entra:


  • Assign the groups to the Maglr app. In Microsoft Entra -> Applications -> Enterprise Applications -> Maglr -> Users and groups, assign the security group(s) you want to use for access filtering.


  • Emit those groups as a token claim. Configure the groups claim to include “Groups assigned to the application” (rather than all groups). This can be set on the application's token configuration, or — if you prefer to keep it entirely within your own tenant — via a claims-mapping policy on the Maglr service principal. Either route works; your IT team can choose based on your internal policy.


  • Share the group IDs with Maglr. The filter values Maglr uses are the group object IDs (GUIDs), for example 7f3a1b20-9ac9-4d7a-8c19-2f4e8b1c9d10. Provide the object ID of each group that should grant access, and we configure the filter for you.


A few things to keep in mind:


  • Only groups assigned to the Maglr app appear in the token. If a group is not assigned, it is not considered for access — even if the user is a member of it.
  • Because the list is limited to assigned groups, the token stays small and the Microsoft “group overage” limit (which truncates very large group lists) is effectively avoided.
  • Access by email domain does not require any of the above — that filter uses the user's email address from their profile and works out of the box.


Domain Filtering by Maglr

Maglr determines the filtering for the secured resource. Based on the data received at sign-in, users can be granted or denied access. The most common filter is by @domain, where users with an email address matching the organization’s domain are granted access. Group-based filtering uses the group IDs delivered in the token, as described above. Filters are configured by Maglr after consultation, tailored to your requirements (see the FAQ below).



Frequently Asked Questions


Which authentication protocol does Maglr use — SAML or OIDC?

Maglr uses OpenID Connect (OIDC) on top of OAuth 2.0, against the Microsoft identity platform. SAML is not used.


Does Maglr need permission to read our directory or all our groups?

No. Maglr requests only the basic user.read profile permission and reads group membership from the sign-in token, limited to the groups your administrator assigns to the Maglr app. Broad permissions such as Group.Read.All or Directory.Read.All are not required.


Can I configure the group-ID filter myself in the dashboard?

Not at this time. There is no self-service settings panel to enter group IDs as a filter, and there is no automatic mapping between Microsoft group membership and a user's rights or roles within Maglr. Instead, Maglr configures a custom filter through our own settings, on request, based on your actual requirements. Just let us know which email domain(s) or group ID(s) should grant access.


Can external design agencies or freelancers log in securely without being part of our Microsoft organization?

Yes. In addition to SSO, Maglr can enable two-factor authentication (2FA) login for external collaborators — such as design agencies and freelancers who work outside your organization but need access to the dashboard or to a published domain. This gives them a secure, verified login without having to be added to your Microsoft tenant.


Can I activate SSO on multiple domains set up within Maglr?

Yes, once the Maglr app is connected, we can create an SSO filter for multiple domains. The “consent” step does not need to be repeated; it is a one-time setup for the entire Maglr application.


Can I grant access to people outside my organization to publications behind my secured domain?

With SSO, only Microsoft users who meet the configured filter criteria will have access. For trusted external collaborators, 2FA login (see above) can be enabled as a separate option.


Can I secure the dashboard itself with SSO for editors/designers in our organization?

Yes. The authorization technically uses the same “Maglr App,” but the setup is managed within the dashboard itself. Read more.

Updated on: 16/06/2026