Opens in a new tab

Critter IT administrator guide

Single Sign-On (SSO) & Email Authentication Configuration

Version 1.0 – November 2026

For organisations using Critter, and for IT administrators of those organisations, to make integration with Critter seamless for their employees.

1. Overview

Critter is a secure, multi‑tenant SaaS platform designed for enterprise environments, that allows users to avoid passwords by using Microsoft or Google single sign on (SSO), and that sends emails to users for various administrative and transactional tasks.

This guide provides IT administrators with the technical details required to:

  • Allow‑list Critter’s Microsoft Entra ID (Azure AD) SSO integration, to enable Microsoft SSO for employees to use to sign in and avoid managing another password.
    • Resolution: Validate Critter’s identity and token usage
  • Ensure reliable email delivery from Critter, so employees can receive emails from the Critter platform
    • Resolution: Configure anti‑spoofing and inbound filtering controls

2. Microsoft Entra ID (Azure AD) SSO

Critter supports secure authentication using OpenID Connect (OIDC) and accepts sign‑ins from:

  • Microsoft Entra ID (Azure AD) work/school accounts
  • Personal Microsoft accounts (MSA)
  • Any Microsoft tenant (multi‑tenant application)

2.1 Common Enterprise Requirements

Your organisation may enforce one or more of the following that would block SSO integration with Critter:

  • Tenant Restrictions v2
    • Resolution: Add Critter’s Application ID to the allow‑list.
  • Conditional Access Policies
    • Resolution: Exclude Critter from restrictive policies or add it to “Allowed cloud apps”.
  • App Consent Policies
    • Resolution: Grant Admin Consent for Critter’s OIDC permissions.
  • Cross‑Tenant Access Settings
    • Resolution: Allow inbound authentication to multi‑tenant applications.

2.2 Critter SSO Configuration

2.2.1 Application Identifiers

  • Tenant ID: 175c95da-c179-4495-8e55-be97f543b95e
  • Application (Client) ID: d212aab2-70aa-49c9-8d5a-0cf3b8c086f7
  • Tenant Model: Multi‑tenant – Critter accepts authentication from any Microsoft tenant.
    • Supported Account Types:
      • Entra ID (work/school)
      • Personal Microsoft accounts (MSA)

2.2.4 OIDC Endpoints

Critter uses the standard Microsoft identity platform endpoints:

  • Authorisation: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
  • Token: https://login.microsoftonline.com/common/oauth2/v2.0/token
  • Logout: https://login.microsoftonline.com/common/oauth2/v2.0/logout
  • JWKS (Signing Keys): https://login.microsoftonline.com/common/discovery/v2.0/keys
  • OpenID Connect Discovery Document: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

2.2.4 Redirect URIs

Critter uses the following redirect URIs:

  • https://app.getcritter.com/identity/sso/microsoft (Web client)
  • com.getcritter.app://oauth2/callback (Mobile & Desktop clients)

2.2.4 Required Permissions

Critter requires these permissions of the Microsoft graph API:

  • User.read (Microsoft Graph)
  • openid, profile, email

💡 Critter does not request any elevated Microsoft Graph permissions.

 

2.2.5 Token Claims Used by Critter

Critter reads a minimal set of standard OIDC claims from the id_token returned from the OIDC token exchange:

Claim Required Purpose
oid Yes If absent, fails authorisation.
preferred_username Yes Used as the email address. If absent, fails authorisation.
given_name Optional Used to identify the user’s first name. If absent, a default nondescript name is used.
family_name Optional Used to identify the user’s last name. If absent, a default nondescript name is used.
name Optional Fallback for absent given_name.
locale Optional Used for the user’s current locale (language and dialect), and fallback for absent ctry.
ctry Optional Used to derive the user’s country and locale.
tenant_ctry Optional Fallback if ctry is absent.

3. Email Authentication

Critter sends transactional emails (for various purposes) using Twilio SendGrid. All outbound email is authenticated using industry‑standard DNS records.

3.1 Common Enterprise Requirements

If your organisation uses strict anti‑spoofing or inbound filtering, this may prevent users receiving email sent by Critter:

  • Allow‑list the sending domain: getcritter.com
  • Allow the return‑path domain: em8394.getcritter.com
  • Allow mail from SendGrid’s envelope‑from domain: sendgrid.net
  • Allow dedicated IPs (if applicable)

💡 Critter does not use shared domains such as sendgrid.net for “From:” headers – all mail is authenticated against getcritter.com

3.2 Critter Email Configuration

3.2.1 Sending Domain

Critter sends email from: getcritter.com

3.2.2 Return-Path Domain 

Used for SPF alignment and bounce handling: em8394.getcritter.com → u59573815.wl066.sendgrid.net

3.2.3 DKIM (DomainKeys Identified Mail)

Critter signs all outbound email using SendGrid DKIM keys:

  • s1._domainkey.getcritter.com → s1.domainkey.u59573815.wl066.sendgrid.net
  • s2._domainkey.getcritter.com → s2.domainkey.u59573815.wl066.sendgrid.net

💡 These are public DKIM selectors.

3.2.4 DMARC Policy

Critter publishes a DMARC policy to support modern anti‑spoofing controls: _dmarc.getcritter.com → v=DMARC1; p=none

3.2.5 Envelope-From Domain

SendGrid uses: sendgrid.net

💡 This is normal and expected for authenticated SendGrid senders.