Canvas LMS SSO with MojoAuth

Connect your Canvas LMS instance (Instructure) to MojoAuth using SAML 2.0. MojoAuth acts as the Identity Provider (IdP); Canvas acts as the Service Provider (SP). Once configured, users can sign in to Canvas with SP-initiated login (from the Canvas login page) or IdP-initiated login (from your MojoAuth-hosted login page or an app launcher).

How it works

Prerequisites

• A MojoAuth project (test or live) with admin access to Developers → Applications.
• Admin access to your Canvas account (root account admin, not just a sub-account or course admin — authentication configuration lives at the account level).
• Canvas SSO (SAML) is available on Canvas instances with SSO enabled by Instructure for your account; if you don't see Authentication under Admin settings, ask your Instructure CSM to enable it for your account.
• Decide up front which Canvas identifier will match the identity MojoAuth sends — Canvas matches incoming SAML assertions to a pseudonym (login) already provisioned in Canvas, typically by email or SIS ID. Canvas does not fully JIT-provision users from a bare SAML assertion, so the matching users must already exist (created manually, via SIS import, or via another provisioning flow) before you test SSO.

Step 1 — Create the MojoAuth SAML connection

1. In the MojoAuth dashboard, go to Developers → Applications → New Application → SAML 2.0 SSO.
2. Enter a connection name (e.g. Canvas LMS – Production) and click Create connection. This creates a draft connection and auto-issues a signing certificate.
3. Leave this tab open — you'll come back to copy the IdP metadata URL and, later, paste Canvas's SP details.

See SAML SSO Connections for the full concept walkthrough.

Step 2 — Configure Canvas

{BASE}/saml/{projectId}/sps/{spId}/metadata

Step 3 — Give Canvas's SP details back to MojoAuth

Canvas generates its SP Entity ID and ACS URL from your institution's Canvas domain and the SAML provider's internal ID:

Back on the MojoAuth SAML connection page:

1. Choose Manual configuration (Canvas does not expose a public SP metadata endpoint you can import from) and enter:
   • SP Entity ID: https://<school>.instructure.com/saml2
   • ACS URL: https://<school>.instructure.com/login/saml/<id> — use the numeric <id> from the authentication provider's edit page URL in Canvas (Step 2).
2. Set NameID format to match what you chose as Canvas's Identifier Format — emailAddress if Canvas will match on email, or unspecified/persistent if matching on a SIS-provided identifier.
3. Click Save.

Step 4 — Attribute / login attribute mapping

Canvas's SAML integration is deliberately minimal: it reads a single Login Attribute from the assertion (usually the NameID) and matches it against an existing Canvas pseudonym (the unique_id on a Canvas login). It does not consume a rich set of SAML attributes the way Workday or Salesforce do.

Configure on the MojoAuth connection's Attribute mappings section:

• If Canvas's Login Attribute is set to match email, set the connection's NameID format to emailAddress and map source: email so the subject itself carries the address Canvas looks up against each user's unique_id.
• If your Canvas logins use SIS IDs rather than email addresses as the unique_id, map source: identifier (populated from your directory's SIS ID field) instead, and set NameID format to unspecified.
• Canvas does not do full JIT user creation from SAML — the unique_id in Canvas must already exist (created via the Canvas UI, SIS import/CSV, or the Canvas API) before a user can complete SSO login. Attribute mapping controls matching, not user creation.

Step 5 — Test

1. From the MojoAuth connection page, use Test SSO to run an IdP-initiated login and confirm a valid signed assertion reaches Canvas's ACS URL.
2. Trigger SP-initiated login directly at:

   https://<school>.instructure.com/login/saml
   This routes to your configured SAML provider (or prompts you to choose one if multiple are active) and redirects to MojoAuth.
3. Sign in with a test account whose unique_id (email or SIS ID) matches an existing Canvas pseudonym. Success looks like: redirect back to Canvas, landing on the Canvas dashboard signed in as that user — no "user not found" or blank login screen.
4. Confirm logout: use Canvas's Logout and check that MojoAuth's SLO endpoint is invoked and the session ends cleanly on both sides.

Troubleshooting

"Certificate Fingerprint" mismatch / signature validation fails The fingerprint (or certificate) stored on the Canvas authentication provider doesn't match MojoAuth's current signing certificate. Re-copy the PEM or fingerprint from Copy PEM / Download .crt on the MojoAuth connection page (certificates rotate periodically) and update the Canvas provider, or re-run Load metadata from URL to refresh it automatically.

Login Attribute / unique_id mismatch ("no matching login found") Canvas received a valid, signed assertion but couldn't find a Canvas pseudonym whose unique_id matches the NameID/Login Attribute value it received. Confirm the connection's mapped source (Step 4) sends exactly the identifier format Canvas expects (email vs SIS ID), including matching case, and verify the target user already has a Canvas login with that exact unique_id.

"Redirect URI" / ACS URL mismatch The ACS URL entered in MojoAuth doesn't exactly match the path Canvas generated for that specific authentication provider (https://<school>.instructure.com/login/saml/<id>). Re-check the provider's edit page in Canvas for the exact <id> and re-save it in MojoAuth's ACS URL field — this is a common source of failures when multiple SAML providers exist on the same account.

User exists in Canvas but SSO still fails Check that the user's login is on the correct pseudonym type — Canvas can have multiple logins per user (e.g. one for SIS, one for Canvas-native), and SAML only matches against the one configured with the Login Attribute you're sending. Look up the user in Admin → People, open their login details, and confirm the unique_id there matches what MojoAuth sends.

Multiple authentication providers cause unexpected default login screen If you've added SAML alongside Canvas login (or another IdP), the Position ordering on Canvas's Authentication page determines what /login shows by default. Use /login/saml to target this specific SAML provider directly, or reorder providers, rather than assuming SAML is the default.

Locked out of Canvas admin after enabling SAML Canvas login typically remains available at /login/canvas even with SAML configured, unless it was explicitly removed. If you're locked out, ask another root account admin to disable or reorder the SAML provider from Admin → Authentication, or contact Instructure support — do not delete your last working authentication provider without a tested fallback.

Related docs

• SAML SSO Connections
• Managing Applications
• Integration Guides overview