How authentik signs AWS users in through IAM Identity Center
If you want AWS access governed by your company identity provider, authentik takes over two jobs and IAM Identity Center keeps the rest. authentik acts as the identity provider for sign-in and as the source of users and groups for provisioning, while IAM Identity Center still owns the AWS permission sets, account assignments and the identity store it evaluates at login. The integration method follows authentik's SAML provider type for the sign-in flow and its SCIM provider type for provisioning, and the AWS side is configured to match those two endpoints. Treat that split as the design baseline before you touch either console.
The SAML flow handles authentication: a user selects the AWS application in authentik, authentik issues a signed assertion, and IAM Identity Center accepts it and maps the subject to an identity store user. The SCIM flow runs separately and creates or updates those users and groups in IAM Identity Center before anyone signs in, so the account exists when the assertion arrives. Your build checklist should record which authentik attribute supplies the SAML NameID, which must match the Identity Center username exactly, and which group attributes drive assignments. Mismatches here are the most common reason a valid login fails.
Before build, confirm the exact AWS console field names, the SAML metadata and SCIM endpoint details, and any authentik edition or plan requirement for these provider types against the current authentik providers documentation and AWS IAM Identity Center documentation. Those sources change between releases, and this page does not pin field names or version-specific behavior. Ask your DeployOpen team to walk through those details with you in writing before work starts, so the scope fixes the exact provider settings, the test accounts and the rollback path.
What you need in place before the AWS and authentik configuration starts
Most delays in this integration come from missing prerequisites rather than from the SAML or SCIM settings themselves. The items below cover the authentik release, the hosting, the AWS side, the group design and the test users, and each one should be settled before anyone opens the admin consoles.
A supported authentik release
Confirm that the authentik version you plan to deploy is on the project's supported list before you configure anything. The security policy names 2026.5.x and 2026.8.x as the lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Plan your upgrade path now so that a later security release does not force an unplanned change to the SAML or SCIM configuration.
Edition that includes SAML and SCIM providers
Confirm on the pricing page which edition includes the SAML and SCIM provider types your design needs before you buy or deploy. The Open Source edition is free but offers community support only, so any paid support or edition terms should be confirmed in writing with authentik. Ask whether your use case depends on any Enterprise-only feature, and check the license file for the directory you plan to use.
Reachable HTTPS endpoint for authentik
AWS and your users must reach authentik over HTTPS at a stable hostname, because the SAML metadata, ACS URL and issuer values all depend on it. Decide the hostname, certificate and reverse proxy before you start, and document where the server and worker containers run. Hosting follows the authentik architecture: a server container, a worker container and PostgreSQL, so plan capacity and backups for all three.
AWS organization and Identity Center administrator
Confirm that the AWS organization and its IAM Identity Center instance already exist, and name one designated administrator who can change the identity source and permission sets. Changing the identity source can affect every account assignment, so record the current state and agree who signs off on changes. Check whether your Identity Center is in the region and account structure you intend to use before building around it.
Authentik group to permission set design
Decide which authentik groups will map to which AWS permission sets before you configure provisioning. Keep the design small enough that an auditor can read it: one group per job function is a common starting point, though your own access model should decide. Write down the owner of each group and who may add members, because group membership in authentik will drive access in your AWS accounts.
Test user set and a rollback plan
Create a small set of test users in authentik that cover each planned permission set, plus one user who should be denied access. Use them to verify sign-in, provisioning and the NameID value before any production user is affected. Also write down how you will revert to the previous identity source if sign-in fails, and confirm that the SCIM endpoint is reachable from the authentik worker container, since provisioning runs there.
Why SCIM should create users before the first AWS login
SAML only signs in an identity that IAM Identity Center already knows. When a user reaches the AWS sign-in page through authentik and the assertion arrives for a user IAM Identity Center has never seen, the login fails or someone has to create the account by hand. Provisioning users and group memberships over SCIM before the first login removes that step. The operational consequence is that the SCIM push, not the first browser login, is the event that makes a person able to reach an AWS account.
In the intended sequence, authentik is the source of truth. Its SCIM provider pushes users and group memberships into IAM Identity Center, creating accounts or updating existing ones. When the user later authenticates through the SAML provider, the NameID in the assertion matches the username IAM Identity Center already holds for that person, so the login resolves to the account that was provisioned. Group memberships pushed by SCIM are what later drive permission set assignments, so a user missing from the right group will sign in successfully and still have no useful access. Check that the group names and membership sync match what your permission design expects before you schedule a go-live.
Before go-live, confirm in writing how authentik and IAM Identity Center handle deletion and deactivation. Ask whether removing a user or group in authentik deletes the IAM Identity Center object, disables it, or leaves it in place, and whether a removed group membership revokes the account assignments it granted. Test this with a disposable user in a non-production instance, including a user removed from a group that still holds access. Your offboarding procedure depends on the answer, and the vendor documentation and your own test results should settle it rather than assumptions made from the SAML side of the setup.
Configuration sequence from authentik SAML provider to a tested AWS login
This sequence connects authentik to IAM Identity Center for SAML sign-in and SCIM provisioning, so that each user exists in Identity Center before first login and can reach AWS accounts through permission sets that match their authentik groups.
Create the authentik SAML provider and application
In authentik, create a SAML provider and an application for IAM Identity Center, then bind them so the application appears in the user's library. Set the ACS URL, audience and NameID mapping that Identity Center expects, and choose the NameID property so that it carries the same value as the Identity Center username (for example, an email address or a stable username, as you have decided in your identity design). Confirm the provider settings with the Identity Center documentation for your Region before saving. Done when the provider saves without validation errors and a test user sees the application in their authentik library.
Export the metadata and signing certificate
Download the SAML metadata from the authentik provider and note the signing certificate and the issuer URL it publishes. Keep the metadata file in your change record, because the Identity Center side needs the exact issuer and certificate values. If the certificate is rotated later, the same export must be repeated and re-imported. Done when you can open the metadata file and find the entity ID, the SSO endpoint and the X.509 certificate that match the authentik provider.
Configure the external identity provider in IAM Identity Center
In the IAM Identity Center console, set the identity source to an external identity provider and upload the authentik metadata. Copy the service provider metadata and the ACS and audience values Identity Center generates back into the authentik provider so both sides agree. Confirm the NameID format matches the value chosen in the first step. Done when Identity Center shows the external provider as configured and the authentik provider lists the matching ACS URL and audience.
Set up SCIM between Identity Center and authentik
Enable automatic provisioning in Identity Center to obtain the SCIM endpoint and an access token. In authentik, create a SCIM provider that uses that endpoint and token, then bind it to the application so that users and groups are pushed on sync. Store the token in your secrets system, because it grants provisioning rights. Done when a test user created in authentik appears in Identity Center with the expected username before that user has signed in once.
Verify provisioned users and groups in Identity Center
Check that the test users and the groups pushed from authentik appear in Identity Center with the correct usernames, names and email addresses. Confirm that group membership in Identity Center matches the membership in authentik, and that removing a user from the authentik group removes the matching membership after the next sync. Note the sync behavior you observe, since deletion and suspension handling should be confirmed against the current authentik and Identity Center documentation. Done when a test user's group membership matches the intended group in both systems.
Assign groups to AWS accounts and permission sets
In Identity Center, assign each provisioned group to the AWS accounts it should reach, and select the permission set for each assignment. Keep one group per permission set where possible so that access reviews remain readable. Review the assignments with the account owners before testing. Done when a table of group, account and permission set matches the access model you approved.
Test the SAML login and permission set access
Sign in as a test user from the authentik user portal, open the AWS access portal from the application tile, and confirm that the user lands on the accounts and permission sets assigned to their group. Repeat the test with a user from each group, and confirm that a user outside the group cannot see the account. Record the NameID that Identity Center shows for each session. Done when each test user reaches the expected account and role, and no user reaches an account outside their assignment.
Document the configuration and retest after changes
Record the authentik provider settings, the Identity Center identity source settings, the SCIM endpoint configuration without the token, and the group-to-permission-set matrix in your runbook. Plan a retest after certificate rotation, authentik upgrades and any change to group membership rules, because each can change the login or provisioning path. Done when the runbook names an owner for each setting and the test cases from the previous step are repeatable by someone other than the author.
Which authentik attributes map to IAM Identity Center users and groups
This table lists the authentik user fields that feed the IAM Identity Center username, email, name and group values, plus the SAML NameID that must match the Identity Center username. Use it as a checklist before you fill in any mapping, and confirm every attribute name against the authentik provider and the Identity Center SCIM and SAML settings in your own tenant first. The main takeaway is that a single character difference in the NameID, including letter case or a missing domain suffix, is enough to make sign-in fail even when the user exists.
| Identity Center attribute | authentik source field | Notes for the mapping |
|---|---|---|
| Username | User username (or a mapped attribute you choose) | Must equal the Identity Center username that SCIM provisions. Confirm whether your Identity Center directory uses an email-style username. |
| SAML NameID | Value sent in the SAML assertion subject, set in the authentik SAML provider | Must match the Identity Center username exactly, including case and any domain suffix such as @example.com if your usernames carry one. |
| User email attribute | Used for contact and notifications. Confirm how your Identity Center settings treat email when it differs from the username. | |
| Given name | User given name attribute (name parts mapping) | Confirm the exact SCIM attribute path expected by Identity Center before mapping the authentik field to it. |
| Family name | User family name attribute (name parts mapping) | Confirm the exact SCIM attribute path expected by Identity Center before mapping the authentik field to it. |
| Group membership | authentik group that the user belongs to | Groups provisioned by SCIM are the basis for permission set assignment in Identity Center. Confirm group naming and whether nested groups are passed. |
| Permission set assignment | Not a user field; set in Identity Center against the provisioned group | Changing a group in authentik only changes access after the group is provisioned and assigned. Confirm sync timing in your environment. |
Choosing the NameID value that matches the Identity Center username
Sending the authentik username as the SAML NameID is the most direct option when the Identity Center username is set to the same value. It fits organizations that already keep one login name per person across directories and treat that name as the stable identifier. Because the value comes straight from the user object, it needs no extra mapping. The risk is that the name must match the Identity Center username character for character, including case and any domain suffix.
- Match the exact string: Confirm whether the Identity Center username is case sensitive in your configuration and whether it includes a domain suffix.
- Watch for renames: A username change in authentik that is not mirrored in Identity Center will cause the next login to fail to match an existing user.
- Check provisioning alignment: If SCIM creates users in Identity Center, the username pushed by authentik should be the same value sent as NameID.
- Confirm the NameID format: Ask your IAM Identity Center administrator which NameID format and attribute the SAML configuration expects, then set authentik to send that exact value.
In a test login, decode the SAML response, compare the NameID with the Identity Center username shown in the console, and confirm the session lands on the expected user with no duplicate account created.
Using the email address as the NameID fits organizations where the Identity Center username is already an email address, or where email is the only identifier the workforce shares. It is also common when people change usernames more often than email addresses. The trade-off is that email addresses can change through marriage, legal name changes or domain consolidation, and aliases can make one person appear under two values. If the Identity Center username is not an email address, every login will fail to match.
- Confirm the Identity Center username format: Check whether it is an email address and whether it matches the primary email in authentik for every user in scope.
- Plan for email changes: Decide who updates an email change and how the username is updated in Identity Center at the same time.
- Handle aliases: Make sure authentik sends only the primary mailbox address, not an alias, as NameID.
- Verify case handling: Email comparisons are often case insensitive in mail systems but not always in identity stores, so test a mixed-case login.
In a test login, check that the NameID in the assertion equals the Identity Center username for the test user and that changing the email in a non-production user does not silently create a second account.
A NameID built from a custom property mapping fits when neither the username nor the email matches the Identity Center username. Examples include a workforce ID, an employee number, or a value that combines a prefix with a stable attribute. This option gives full control over the value but moves the alignment logic into a mapping that someone must own and maintain. It is the option most likely to drift silently after a later change to the mapping or the source attributes.
- Define the source attribute: Name the authentik user attribute the mapping reads and confirm that it is populated for every user before onboarding.
- Keep the transformation simple: Avoid string logic that depends on other fields, since a change in one field alters the NameID for the whole population.
- Mirror the value in Identity Center: The same identifier must be stored as the Identity Center username, or the sign-in will not resolve.
- Review the mapping on change: Treat edits to the property mapping as changes that need a test login and a record in your change log.
In a test login, compare the mapped value in the assertion with the Identity Center username, then repeat the check for a user whose source attributes were edited to confirm the mapping still produces the documented value.
Security settings that protect the AWS sign-in path
The AWS sign-in path runs through two systems that each hold keys to access: the SAML trust that authentik presents to IAM Identity Center and the SCIM channel that creates and removes users ahead of login. The cards below cover the decisions a security team should make and verify on both sides, and the evidence to keep once the integration is live.
Protect the SAML signing certificate
The signing certificate authentik uses for SAML assertions is the trust anchor for every AWS sign-in. Decide who can export or replace the private key, where it is stored, and who approves a rotation. Confirm that IAM Identity Center is updated with the new certificate before the old one expires, so a rotation does not lock out all AWS users. Record the certificate fingerprint and expiry date in your change system.
Restrict which groups reach AWS
Assigning an application in authentik is the gate for AWS sign-in, so the bindings on that application determine who can start the flow. Use a dedicated group for AWS access instead of broad staff groups, and confirm that disabled or departed users are removed from it. Test with a non-privileged account to confirm that users outside the group are refused before they reach Identity Center.
Scope and rotate the SCIM token
The SCIM token lets the provisioning channel create, change and delete users and groups in IAM Identity Center, so it carries write access to your workforce directory. Limit it to the single provider it serves, store it in a secrets manager, and document a rotation procedure with an owner. Confirm which audit trail in AWS records changes made under this token so you can separate automated changes from manual ones.
Require MFA for AWS users in authentik
Identity Center can enforce its own MFA, but authentik is the system that authenticates the user before the assertion is issued. Decide where MFA is enforced, then bind an authentication flow with a second factor to the AWS application so that users cannot reach AWS on password alone. Confirm which factors your users may enroll, and check that recovery flows do not offer a path that skips the second factor.
Limit who administers the SAML provider
Changes to the SAML provider, its mappings or its bindings can alter what every AWS user receives. Restrict the authentik administrator role to a small named group, separate it from the group that manages applications for other systems, and require a second reviewer for changes to NameID or attribute mappings. Review the membership of that group on a fixed schedule and after staff changes.
Forward authentik audit events
Sign-in, assertion, provider and administrator events from authentik are needed to investigate an AWS access question after the fact. Decide which event types go to your log platform, how long they are kept, and who can read them. Confirm that the log forwarding is working by generating a test sign-in and finding it in the destination, and alert on changes to the SAML provider or to the AWS application bindings.
Failures that appear after the AWS integration goes live
This table lists the failures teams most often see once authentik sign-in into IAM Identity Center is live, with the likely cause and the first check to run for each. Read it as a triage order: confirm the identity match and group assignment before you look at certificates or SCIM plumbing.
| Symptom | Likely cause | First check to run |
|---|---|---|
| SAML login reaches IAM Identity Center but finds no matching user | The SAML NameID sent by authentik does not equal the Identity Center username for that user | Decode a test assertion and compare the NameID value with the username shown in Identity Center, character for character |
| User signs in but has no permission sets | The user is valid but is not a member of a group assigned to an AWS account with a permission set | Check the user's group membership in Identity Center, then confirm that group has an account assignment with the expected permission set |
| SCIM pushes from authentik fail with authorization errors | The bearer token is expired, rotated or copied incorrectly, or the SCIM endpoint URL does not match the one Identity Center issued | Review the failing request in the authentik SCIM sync log for HTTP status and error text, then re-issue the token and confirm the endpoint |
| SCIM pushes fail with endpoint or connection errors | The SCIM base URL is wrong, the Identity Center endpoint changed, or a proxy or firewall blocks outbound requests from the authentik worker | Test the endpoint from the worker container, confirm the base URL in the provider settings and check the worker logs for connection failures |
| User exists in authentik but not in Identity Center | The provisioning run has not executed, the user is excluded by a group or property filter, or the user lacks required attributes | Open the SCIM sync log for that user, check the provider's mapped scope and filters, then trigger a sync and confirm the result |
| Users who signed in earlier are suddenly rejected | The SAML signing certificate in authentik or in Identity Center has expired or been replaced without updating the other side | Check certificate validity dates on both sides and confirm the certificate in Identity Center matches the one authentik signs with |
| Assertion is accepted but sign-in lands on the wrong account | Two accounts share an email or username, or the NameID format differs from the one Identity Center expects | Compare the NameID format and value for the affected user against the Identity Center user record and look for duplicate identities |
Questions teams ask before connecting authentik to AWS IAM Identity Center
What does connecting authentik to IAM Identity Center cost, and what is one-time versus recurring?
The cost has two parts: a one-time build and a recurring run cost. The build covers design of the SAML application and SCIM provisioning, the attribute and NameID mapping, permission set design, testing with pilot users and cutover. Recurring costs include the platform you run (authentik itself is free under its open-source edition, but the hosting, PostgreSQL, backups and monitoring are yours to pay for), any support retainer, and the effort to review group membership and deprovisioning. Ask each vendor or partner for a written scope that separates these lines. Ask for a quote that lists the number of AWS accounts, permission sets and identity sources in scope, because those are the main drivers of the one-time price.
How long does the build take, and what makes it take longer?
Duration depends on scope and on how clean your identity data is, not on the protocol alone. The biggest variables are the number of AWS accounts and permission sets, how many groups need to map to access, whether your directory has duplicate or stale accounts, and how many approvals the change needs in your own change process. A narrow build with one or two accounts and clear group design moves faster than a multi-account estate where group ownership is unclear. Ask for a timeline in the written scope with named milestones, and confirm which steps depend on your AWS or authentik administrators being available.
What must our team provide before the work starts?
The work needs access and decisions from your side before any configuration begins:
- AWS administrative access to IAM Identity Center, including the ability to enable automatic provisioning and create permission sets in the management account.
- authentik administrative access, including rights to create providers, applications, property mappings and flows.
- A written group design that maps each business role to a group and each group to a permission set in each account.
- A set of test users covering each role, plus a named owner to approve test results.
Also confirm who owns the identity source that authentik reads from, since that team decides which accounts exist before login.
Can our internal team build this without an outside partner?
A team that already runs authentik and understands AWS Identity Center can build the integration in-house, provided it has time, access and someone who has done SAML and SCIM work before. Teams without that experience usually lose time on NameID alignment, certificate exchange and SCIM attribute mapping, where small mismatches cause login failures that look like permission problems. An outside partner is most useful for a fixed-scope build with written deliverables, verification evidence and a handover your operators can run. Either way, the first decision is who owns the group design and the cleanup of existing accounts, because that work often takes longer than the configuration.
Which authentik edition do we need for SAML and SCIM with IAM Identity Center?
The SAML and SCIM provider types described in the authentik documentation are part of the platform's provider set, and the open-source edition is free under the MIT license for most of the code. Enterprise-only features on the pricing page are different: Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management, password history, enhanced audit logging and ticket-based support. If your design needs one of those, such as enhanced audit logging for a regulated audit trail, the Enterprise edition is required for that feature. Confirm the exact provider and feature list against the current pricing and providers pages before you commit to a design.
What changes when we add AWS accounts, permission sets or users later?
Adding users is routine once provisioning works, because SCIM creates and updates identities from authentik. Adding accounts or permission sets is a design change: each new account needs group assignments, and each new permission set needs a clear owner and review rule. Removing people also needs a tested path, since deprovisioning and session expiry decide how quickly access ends. Plan a change procedure with a test user, a rollback step and a review of group membership at a set interval. Ask any partner to include this procedure in the handover so your team can run it without a new engagement.
What is the most common reason the SAML login fails?
The most common cause is a mismatch between the SAML NameID and the username IAM Identity Center expects. The NameID must match the Identity Center username for the user to be recognized, so the authentik property mapping has to produce the same value that SCIM provisioned. A second common cause is a certificate or metadata change that was not carried into the other side. When a login fails, check the NameID value in the SAML response, the username stored in Identity Center for the same user, and the signing certificate on both sides before changing permissions.
What should we ask for in a quote for this integration?
Ask for a written scope that lists the AWS accounts and permission sets in scope, the authentik providers and applications to be created, the identity source and its cleanup needs, the test plan and acceptance criteria, and the handover items. Ask which items are one-time and which recur, such as support or periodic access reviews. Ask who performs each task and which tasks need your staff. A quote without these items cannot be compared with an internal estimate. DeployOpen plans and implements these integrations under fixed-scope agreements, with deliverables and timelines agreed in writing before work starts.
How DeployOpen scopes, delivers and supports the authentik and AWS integration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so authentik and its SAML and SCIM connection to AWS IAM Identity Center run in your accounts and under your control. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- The written scope names the authentik version, the AWS accounts and Identity Center instance involved.
- It lists which permission sets, groups and AWS accounts are in scope for federated sign-in.
- It records who approves the NameID decision and the attribute mapping before build starts.
How we build
- We deploy authentik in your infrastructure and configure the SAML provider and application for Identity Center.
- We set up SCIM provisioning so users and groups exist in Identity Center before their first login.
- We test sign-in for each permission set and confirm NameID matches the Identity Center username.
How we hand over
- You receive configuration records, mapping settings and a runbook covering the SAML and SCIM setup.
- Test cases and results for login, provisioning, deprovisioning and group membership are documented.
- Your team is walked through how to rotate certificates and handle failed SCIM sync events.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning covers authentik release changes that could affect the SAML or SCIM configuration.
- Confirm with us in the quote which support hours and response terms apply to your environment.
