AWS IAM Identity Center SSO with MojoAuth
Connect AWS IAM Identity Center (opens in a new tab) (formerly AWS Single Sign-On) to MojoAuth using SAML 2.0. MojoAuth acts as the external identity provider (IdP) and AWS IAM Identity Center is the service provider (SP) — users authenticate with MojoAuth and land in the AWS access portal, where they can open any assigned account or application.
How it works
IAM Identity Center does not support just-in-time (JIT) provisioning over SAML. The user's email (NameID) must already exist as a user in Identity Center — either created manually or provisioned via SCIM — before they can sign in through MojoAuth.
Prerequisites
- A MojoAuth project (test or live) with access to Applications → SAML 2.0 SSO connections.
- AWS management/delegated administrator access to IAM Identity Center, with permission to change the identity source.
- IAM Identity Center must already be enabled in your AWS Organization (it's free — no separate paid edition is required for external IdP SAML SSO).
- The users who will sign in via MojoAuth must exist in IAM Identity Center already (manually created, or synced in via SCIM from MojoAuth or another directory). This guide covers SSO only, not provisioning.
Step 1 — Create the MojoAuth connection
Create a SAML 2.0 SSO connection
In the MojoAuth dashboard: Developers → Applications → New Application → SAML 2.0 SSO. Enter a
connection name (e.g. AWS IAM Identity Center) and select Create connection.
This creates a draft connection and auto-issues a signing certificate. You'll come back to finish it in Step 3, once you have AWS's SP details. See SAML SSO Connections for background on connections in general.
Copy MojoAuth's IdP values
On the connection page, copy the following — you'll paste these into AWS in Step 2:
| Value | URL |
|---|---|
| IdP metadata URL | {BASE}/saml/{projectId}/sps/{spId}/metadata |
| IdP SSO URL (sign-in URL) | {BASE}/saml/{projectId}/sps/{spId}/sso |
| IdP SLO URL (logout) | {BASE}/saml/{projectId}/sps/{spId}/slo |
| IdP Entity ID (issuer) | same as the IdP metadata URL |
| IdP signing certificate | "Download .crt" / "Copy PEM" on the connection page |
Step 2 — Configure AWS IAM Identity Center
Switch the identity source to an external IdP
In the AWS IAM Identity Center console (from the account that owns Identity Center): Settings → Identity source tab → Change identity source, then select External identity provider and continue.
Grab AWS's service provider metadata
AWS shows you its own SP metadata on this same screen — this is what MojoAuth needs to accept assertions from AWS:
- AWS SSO ACS URL (Assertion Consumer Service URL)
- AWS SSO issuer URL (the SP entity ID)
- A downloadable AWS SAML metadata file (contains both of the above, plus AWS's SP certificate)
Keep this tab open, or download the metadata file — you'll need the ACS URL and issuer URL (or the file itself) in Step 3.
Upload MojoAuth's IdP metadata to AWS
Still on the Change identity source screen, under Identity provider metadata, provide MojoAuth's side. AWS accepts either:
- Upload a metadata file — save the contents of MojoAuth's IdP metadata URL
(
{BASE}/saml/{projectId}/sps/{spId}/metadata) as an XML file and upload it, or - Enter values manually:
- IdP sign-in URL → MojoAuth's IdP SSO URL (
{BASE}/saml/{projectId}/sps/{spId}/sso) - IdP issuer → MojoAuth's IdP Entity ID (the metadata URL)
- IdP certificate → upload the MojoAuth signing certificate (.crt/.pem) you downloaded in Step 1
- IdP sign-in URL → MojoAuth's IdP SSO URL (
Select Next, review the summary (AWS will warn that current AWS Management Console credentials users use will now authenticate against the external IdP), and confirm to finish changing the identity source.
Changing the identity source affects the whole AWS Organization's Identity Center instance. Test with a pilot user/group before rolling out broadly, and keep a break-glass admin account that can still sign in (e.g. root or an IAM user) in case the SAML configuration needs fixing.
Step 3 — Give AWS's SP details back to MojoAuth
Back on the MojoAuth SAML connection page from Step 1, finish the draft with AWS's SP information:
- Import from metadata — paste the AWS SAML metadata file's contents or upload the file you downloaded in Step 2, or
- Manual configuration — enter:
- SP Entity ID → the AWS SSO issuer URL
- ACS URL → the AWS SSO ACS URL
Set NameID format to emailAddress — AWS matches the incoming assertion's NameID against a user's
primary email address in Identity Center, so the NameID must be the exact email address of an
existing Identity Center user.
Leave Sign assertion enabled (recommended). Select Save to activate the connection.
Step 4 — Attribute mapping
AWS IAM Identity Center's SAML SSO only requires the NameID (email) to identify the user — there are no additional required attributes for sign-in itself. Configure the connection's attribute mappings as follows:
saml_name (attribute AWS expects) | source | name_format |
|---|---|---|
| (NameID) | email | — set via the connection's NameID format field, not the attribute table |
https://aws.amazon.com/SAML/Attributes/RoleSessionName | email | uri |
The RoleSessionName attribute above is only relevant if you separately configure AWS IAM (not
Identity Center) role federation directly against MojoAuth for a specific account/role. For the
standard IAM Identity Center external-IdP flow described in this guide, the NameID (email) is all
that's required — permission sets and account access are assigned inside Identity Center itself, not
passed via SAML attributes.
Step 5 — Test
Confirm the user exists in Identity Center
Before testing, make sure the account you're signing in as already exists as a user in IAM Identity Center (Users tab) with an email that matches what MojoAuth will send as NameID, and has at least one permission set assigned to an AWS account.
Test from MojoAuth (IdP-initiated)
On the connection page, select Test SSO. MojoAuth authenticates you and posts an assertion to AWS's ACS URL. Success looks like landing directly in the AWS access portal (or being redirected into an assigned account), without an AWS-hosted sign-in prompt.
Test from AWS (SP-initiated)
Visit your AWS access portal URL (https://<your-subdomain>.awsapps.com/start, shown on the Identity
Center dashboard settings page). It should redirect straight to MojoAuth's hosted login. After
authenticating, you should land back on the access portal with your assigned accounts and permission
sets listed.
Troubleshooting
"We can't find your account" / user not found in Identity Center
The NameID MojoAuth sent doesn't match any user's primary email in Identity Center. Confirm the
connection's NameID format is emailAddress and that the source is email, and that a user with
that exact email already exists in Identity Center (JIT provisioning is not supported — create the user
manually or provision via SCIM first).
AWS rejects the assertion with an audience / issuer mismatch The SP Entity ID saved on the MojoAuth connection doesn't exactly match the AWS SSO issuer URL shown on the identity source page. Re-copy it (or re-import the AWS metadata file) — trailing slashes and region-specific paths matter.
ACS URL mismatch / "invalid destination" error The ACS URL configured on the MojoAuth connection doesn't match the AWS SSO ACS URL exactly. Re-check for typos or an outdated value — AWS regenerates this value if you ever recreate the Identity Center instance in a different region.
"Invalid signature" or certificate errors on the AWS side AWS is validating the assertion against a stale or wrong certificate. Re-download MojoAuth's current signing certificate from the connection page and re-upload it under Identity provider metadata in AWS. If MojoAuth's certificate was rotated, this step must be repeated.
Sign-in loops back to the MojoAuth login page after authenticating
Usually caused by a NameID format AWS doesn't accept, or the assertion being unsigned. Verify NameID
format is emailAddress and Sign assertion is enabled on the MojoAuth connection.
User signs in but sees no accounts or applications Authentication succeeded, but the user has no permission sets assigned in Identity Center. This is expected — SAML SSO only authenticates the user; assigning accounts, permission sets, and applications is a separate step done inside IAM Identity Center (AWS accounts / Applications tabs).
Locked out after switching the identity source If the external IdP configuration is broken and admins can't sign in, use a break-glass IAM user or the AWS account root user (outside Identity Center) to sign back into the console and switch the identity source back to the internal directory while you fix the SAML configuration.