Strapi SSO and authentication guide

Why Strapi SSO and authentication are two separate builds

Strapi SSO covers only administrator login to the admin panel through an identity provider, and it is available on the Growth add-on or the Enterprise plan. End-user authentication for your website or app is a separate concern, handled by the Users and Permissions plugin, JWTs and third-party providers. When a team asks for "single sign-on for Strapi," it usually means two things at once: staff signing in to the admin panel with corporate credentials, and customers or members logging in on the front end. These surfaces have different users, different settings, different failure modes and different owners, so scope them as two workstreams from the first planning conversation and estimate each one on its own.

The first complication is plan gating. SSO for the admin panel is not part of the Community plan, so a project that starts on Community and later needs corporate sign-in will have to add the Growth add-on or move to Enterprise. Check the current plan terms on Strapi's self-hosted pricing page before design starts, because the cost of the admin SSO feature changes the total cost of ownership. The second complication is role mapping. SSO can register new administrators automatically and assign a default role, but your identity provider groups still have to be translated into Strapi admin roles. Decide in advance which groups map to which roles, who approves changes to that mapping and how a user who leaves the organization loses access.

The third complication is lockout risk. Strapi's SSO settings include an option to lock out local login, which is useful for enforcing corporate sign-in but dangerous if the identity provider setup is wrong. An administrator who cannot sign in through the provider and cannot use a local account may have no route back into the admin panel. Keep at least one tested break-glass administrator with a documented recovery procedure, and verify sign-in in a staging environment before changing anything in production. Also note that the Strapi SSO documentation names Microsoft Azure Active Directory as an example provider. Confirm with Strapi and your own provider's configuration guide that your specific identity provider, tenant setup and protocol are supported before you commit to a design.

Which Strapi components handle admin SSO and end-user login

Strapi separates administrator sign-in to the admin panel from end-user sign-in to your API and front end. Each of the components below governs one of those paths, and each has a different owner, so the build plan should assign them before configuration starts.

Admin panel SSO and auto-registration

Admin SSO connects administrator login to an identity provider such as Microsoft Entra ID (formerly Azure Active Directory). Strapi's SSO documentation describes auto-registration, which creates an admin account on first sign-in, and a default role assigned to those accounts. The default role should be the least-privileged role your team can work with, because any user your identity provider admits can receive it. Confirm the current option names against your Strapi 5 minor version, since they can change between releases. Owner: administrators.

Optional local login lock-out

Strapi's SSO feature can be configured to disable local email and password login to the admin panel, so administrators must sign in through the identity provider. This matters when you need a single control point for offboarding and multi-factor enforcement. Before enabling it, confirm with your Strapi version how a locked-out instance can be recovered if the identity provider is unavailable, and document who holds that recovery path. Owner: administrators.

Users and Permissions plugin for end users

End-user accounts, such as customers, members or contributors who sign in to content, are handled by the Users and Permissions plugin, not by admin SSO. It manages registration, login, password reset and the roles that decide which content and routes a user can reach. Public and authenticated role permissions should be reviewed against each content type. Owner: end users are accounts managed by administrators, while the permission model is set by the project team.

JWT issuance for API access

When a user logs in through the Users and Permissions plugin, Strapi issues a JSON Web Token that the client sends with API requests. Token lifetime, signing secret handling and how the front end stores the token determine how long a stolen token stays useful. Confirm the token settings for your version and keep the signing secret in environment configuration, not in code. Owner: the project team sets the configuration, and the front-end team stores and sends the token.

Third-party providers for front-end sign-in

Social or external identity providers can sign end users in through the Users and Permissions plugin's provider settings. Each provider needs a registered application, callback URLs for every environment, and a decision about whether first sign-in creates a Strapi user. Callback mismatches are a common cause of failed sign-in after deployment. Owner: the front-end team manages the sign-in flow, and administrators manage the provider registrations.

Separating admin and end-user boundaries

Admin SSO and end-user login use different identities, roles and tokens, and confusing them is a frequent design error. An administrator account should never be reused for front-end access, and an end-user token should not be accepted by admin routes. Test both paths with separate accounts in a staging environment before launch. Owner: the project team, with security review.

Decisions to make before configuring Strapi SSO

This table compares the choices to settle before enabling SSO for Strapi administrators and before setting end-user login for your front end. Read each row as a decision with its options, its operational cost and the situation where each option fits. The main takeaway is that plan choice and the local login path are hard to change once staff depend on them, so settle them first.

Decision	Option	Operational cost	Choose it when
Plan for admin SSO	Growth with SSO add-on	Recurring: Growth lists at 45 US dollars per month for 3 users, plus 15 per extra user (Strapi self-hosted pricing page)	A small admin team fits the plan limits and you accept the add-on fee
Plan for admin SSO	Enterprise, SSO included	Custom pricing; request a written quote covering users, audit logs and support terms	You also need audit logs or review workflows, or the admin count is large
Admin account creation	Auto-registration on first sign-in	Accounts appear without a ticket; leavers still need checks in both the identity provider and Strapi	Many staff need access and identity provider groups already control who signs in
Admin account creation	Pre-provisioned administrators	Each account is created by hand; reconciliation effort rises with every joiner and leaver	The admin team is small and stable, and each account needs a named owner
Default role for new admins	Least-privilege default role	Low blast radius; admins who need more access must be upgraded by another admin	Most organizations, so elevated roles are granted deliberately
Local admin login	Keep local login as break-glass	A stored credential to vault, test and rotate; it remains a password attack target	An identity provider outage or misconfiguration would otherwise lock out every admin
Local admin login	Disable local login	Lock-out risk if the identity provider or SSO setup fails; recovery needs database or operations access	Policy requires all admin access through the identity provider and the recovery path has been tested
End-user authentication	Local credentials via Users and Permissions	Your team builds and runs registration, password reset and account lifecycle	The site has a small user base and no need for external identity providers
End-user authentication	JWTs or third-party providers	Token issuance, expiry and provider terms are your design; confirm provider costs before choosing	Customer-facing front ends need social or enterprise sign-in, separate from admin SSO

How to configure Strapi admin SSO step by step

This sequence takes an administrator sign-in from plan confirmation to a tested identity provider login with least-privilege roles and a documented break-glass path. It then covers the separate end-user track, so admin access and public or customer access are each verified on their own. Each step ends with a check you can record.

Confirm SSO is in the plan
The admin owner checks the Strapi plan before any configuration starts. In self-hosted plans, SSO is an add-on for the Growth plan and is included in Enterprise, so a Community install needs a plan change or add-on purchase first. Confirm the subscription with Strapi, record which users will be administrators, and confirm the Node.js and database versions against the installation requirements for your release. Check: the admin account shows SSO as an available feature, and the scope document names the identity provider and the people who will sign in through it.
Register the Strapi admin application
An administrator of the identity provider creates an application for the Strapi admin panel. Record the redirect URI, the tenant or directory identifier, the client ID and the client secret, and copy the exact redirect URI format from the Strapi SSO documentation for your version. Assign access only to the groups that should reach the admin panel. Check: the provider's test or sign-in preview reaches the redirect step without error, and the client secret is stored in your secrets vault, not in a ticket or chat thread.
Set provider configuration in environment variables
The platform engineer adds the provider settings to the Strapi environment, keeping the client secret out of configuration files committed to source control. Use the variable names listed in the SSO documentation for your version, and set them per environment so staging and production use separate registrations. Restart the instance and confirm it starts without missing-variable errors. Check: the admin login page shows the SSO sign-in option in staging, and the client secret does not appear in application logs or in any admin output you can view.
Test sign-in with a non-administrator account
Before enabling auto-registration, sign in through the provider with a test account that is not in any group mapped to Strapi admin access. This shows what Strapi does with an unknown user and whether a first login creates an admin account. The test owner records the result, removes any account Strapi created by mistake, and confirms which group claims the provider sends. Check: the sign-in either fails the way the documentation describes or creates an account with the default role you expect, and no account with elevated rights appears.
Set least-privilege default and group mappings
Choose the lowest-privilege admin role that still lets a new user do the job, and set it as the default for auto-registered accounts. Where your Strapi version and identity provider support mapping groups to Strapi roles, map only the groups that need content or settings access, and leave all other groups unmapped. The security owner reviews each mapping before it goes live. Check: a test user in an unmapped group receives the default role, and a test user in a mapped group sees only that role's permissions in Content Manager and Settings.
Decide and test the break-glass lock-out
Decide whether local username and password login stays available. If you enable the local login lock-out, create a documented break-glass administrator with a strong password held in a sealed record, and document who may use it and under what conditions. Test that path in a non-production environment, simulating a provider outage, and have the operations owner sign off the written procedure. Check: the break-glass account signs in during the simulated outage, and a normal SSO user can no longer sign in with a local password once the lock-out is active.
Create end-user roles and permissions
This is a separate track from admin SSO. Configure the Users and Permissions plugin for end users by creating the roles your application needs. Set public and authenticated permissions for each content type and custom route, starting from no access and adding only what the front end requires, and scope any API tokens the same way. Document each role and its permissions so the front-end team and the security reviewer work from the same list. Check: an unauthenticated request to a protected endpoint is denied, and an authenticated low-privilege user is refused any action outside its role.
Issue and verify JWTs and front-end providers
Confirm that login and registration return a JWT and that protected requests succeed with a valid token. Test expiry by submitting a deliberately expired token, which must be rejected, and test a tampered token the same way. If the front end needs third-party providers, register each provider application, add its settings in Strapi, and test the full redirect flow from the front end's staging host. Check: a valid token reads protected content, expired and altered tokens are rejected, and a third-party sign-in creates an end-user record with the intended role.

How to protect admin and end-user access in Strapi

Authentication hardening in Strapi covers two groups: administrators who sign in through SSO and end users who log in with the Users and Permissions plugin. The six controls below address secrets, admin access, default roles, public permissions, token lifetimes and logging, and most of them require a decision from your team before launch.

Keep secrets out of source control

Provider client secrets, the admin JWT secret and the application keys belong in environment variables or a secrets manager, injected at deploy time. Check that the Git history, container images and CI logs contain none of them, and rotate any value that has ever been committed. Confirm which values your Strapi version reads from the environment, and assign an owner to each secret so rotation has a clear process.

Restrict admin panel access and SSO changes

Limit who can reach the admin panel by placing it behind a VPN, a private network or an allowlist where your architecture permits, and keep it separate from the public API. Restrict which admin roles can edit SSO provider settings, since a wrong provider setting or redirect URL can lock administrators out. SSO itself is an add-on on Growth and included in Enterprise, so confirm your plan before you design around it.

Review the SSO default role

With auto-registration enabled, each first-time sign-in creates an administrator account with the default role, so that role decides what every new identity can change. Start from the most restrictive role that fits, and confirm its content type, settings and plugin permissions before enabling auto-registration. Test with a non-admin identity from your provider and verify the resulting access in the admin panel.

Lock down public and authenticated roles

The Public and Authenticated roles control what anonymous visitors and logged-in end users can call through the REST and GraphQL APIs. Set the actions for each content type explicitly, and remove create, update and delete rights from both roles unless a front end needs them. Test every route with no token and with a standard end-user token, because any permission granted to Authenticated applies to every registered user.

Set JWT lifetimes and plan revocation

Strapi issues JWTs signed with a server secret for both admin and end-user sessions. Choose a token lifetime short enough that a stolen token has limited use, and add a refresh flow in your front end if sessions must last longer. A signed JWT stays valid until it expires, so confirm in your Strapi version's documentation how revocation works, and treat rotating the signing secret as the emergency option that ends all active sessions.

Log sign-in events on each plan

Audit logs are an Enterprise feature in Strapi's self-hosted plans, so Enterprise teams can use them to record sign-ins and administrative changes. Growth teams need another path, such as collecting authentication events from the identity provider's sign-in logs and forwarding Strapi application logs to a central log store. Confirm what each source records, how long it is retained and who reviews it.

How the authentication setup changes by deployment model

On a single node, one Strapi process serves the admin panel from one host. The callback URL is a single public address for that host, and it must be registered with the identity provider exactly as the browser sees it, including the scheme, host and path. Secrets are usually loaded from environment variables on the server or from a secrets file readable only by the service account.

Callback URL: one address, typically the admin panel hostname. Confirm the exact redirect format the provider requires, including trailing slashes and port numbers.
Secrets: the client secret is supplied through the host environment and kept out of the source repository and build artifacts.
Provider reachability: the server must reach the provider's endpoints outbound, and administrator browsers must reach the provider's sign-in pages.
Sessions and JWTs: because only one process holds the signing keys, key changes apply immediately to every session. Check how your configuration handles a key rotation before scheduling one.

Before go-live, check the registered callback URL against the production hostname and TLS configuration, and confirm both with the provider.

How to verify that Strapi SSO and end-user login work and fail safely

Verification for this topic has two tracks that must be tested separately, because Strapi SSO covers only administrator login to the admin panel, while end-user authentication runs through the Users and Permissions plugin. Start by writing one test case per behavior you rely on, with the expected result, the tester, the environment and the evidence to be captured. For the admin track, confirm that a user who exists in the identity provider and is assigned to the Strapi application can sign in and reach the admin panel. Then confirm the less obvious behaviors: a user removed from the identity provider must be refused at the next sign-in attempt, and a newly auto-registered user must receive only the default role you configured, not an Editor or Super Admin role by accident. Check the role assignment in the admin panel itself, not only in the identity provider. The local lock-out path needs its own test because it is the control that keeps the admin panel reachable when the identity provider fails. If you enable local login lock-out, verify that password login for administrators is refused as designed, and then verify that the break-glass account can still sign in. Test the break-glass recovery end to end: sign in with it, confirm its role and permissions, and confirm that its use generates an alert or log entry in your monitoring. Keep the break-glass credential out of day-to-day use and record when it was last tested. Whether your plan includes audit logs for administrator actions is a point to confirm against the current Strapi self-hosted pricing page before you rely on those logs as evidence. For end-user login, test registration and login through the Users and Permissions plugin against the public and authenticated routes you defined in your permission settings. Public routes should return data to an anonymous request, while authenticated routes must refuse the same anonymous request. Submit a JWT that has expired and a JWT whose payload or signature has been altered, and confirm both are rejected. If you use a third-party provider, complete a login from the front end and confirm the session is established and the user receives only the permissions you intended. Confirm the JWT lifetime and provider settings with the Strapi documentation for your installed version rather than assuming defaults. Failure-mode tests matter as much as success paths. Simulate an identity provider outage and confirm that administrator access degrades in the way your design expects, with the break-glass path working and no silent fallback to weak access. Test a wrong redirect URI in the identity provider configuration and confirm the sign-in fails with a clear error rather than exposing tokens. Revoke a test user in the identity provider and confirm the revocation takes effect in Strapi within the time you have agreed, noting that session lifetime affects this result. Record each result with a date, the build or configuration version, the tester and the screenshot or log extract. Keep these records as evidence for periodic access reviews, so that an auditor or internal reviewer can see which accounts were tested, which roles they received and how failures were handled.

What drives the effort and cost of Strapi authentication work

This table lists the factors that change how much work Strapi SSO and end-user authentication require, what raises each one, and what keeps it contained. Read each row against your own administrator count, identity providers, and environments before asking for a quote. The main takeaway is that scope agreed in writing up front, with fewer roles and one identity provider per environment, usually matters more than any single technical choice.

Driver	Why it raises effort	How to keep it down
Administrators and groups	Each admin account, and each group mapped to a Strapi role, needs testing for login, auto-registration and role assignment. Many groups mean many mapping rules to verify.	Map a small number of identity provider groups to a few Strapi roles. Agree the group-to-role table in writing before build starts.
Identity providers or tenants	Each identity provider needs its own connection settings, claim mapping, certificates or client secrets, and test logins. Multiple tenants multiply that work.	Use one identity provider per environment. Confirm in writing whether a second tenant is in scope or a later phase.
End-user population	Internal staff, customers, or both need different sign-up, verification, password reset, and account lifecycle flows. Customer-facing login adds more abuse and recovery cases.	Start with one population and one login method. Add the second track as a separately scoped phase.
Roles and permissions on content types and custom APIs	Every content type, field, and custom route can carry its own permission per role. Combinations grow quickly and each needs an acceptance test.	Reuse a tested permission matrix. Keep roles few and review public API permissions once, then freeze them for the release.
Custom JWT or session behavior	Changes to token lifetime, claims, refresh handling, or session storage move the work from configuration into custom code and security review.	Keep the default Users and Permissions JWT behavior unless a documented requirement needs otherwise. Record each deviation as its own item.
Front-end third-party sign-in	Each front-end framework and each external provider needs its own callback URLs, token exchange, and session handling. Mobile apps add separate flows.	List the front ends and providers in scope. Limit the first release to the framework and provider the business actually uses.
Compliance evidence requirements	Assessors may ask for access reviews, configuration records, and proof of MFA or lock-out settings. Collecting that evidence adds documentation and test runs.	Confirm with your auditor which evidence they need before build. DeployOpen prepares evidence; auditors and certification bodies issue any assessment.
Number of environments	Development, test, staging, and production each need their own identity provider registration, secrets, and redirect URLs, and each needs its own verification pass.	Keep environment differences to configuration values. Automate configuration where the platform allows it.
What to ask for in a quote	A quote without defined tracks leads to disputed scope later. Ask for the admin track and end-user track listed separately, with the environments covered and the acceptance tests for each.	Request a written scope that names the environments, the acceptance test list, and what is excluded, including any later phases.

What to monitor, back up and document after go-live

After go-live, the most useful signal is the sign-in path itself. Track failed administrator sign-ins through the identity provider's logs and through Strapi's own logs, and alert on spikes and on any lock-out. A broken redirect URI, an expired provider secret or a changed group claim often looks like a lock-out to editors, so the alert should reach a named owner who can check the provider configuration first. Keep end-user authentication on a separate watch list. Failed logins and rejected JWTs handled by the Users and Permissions plugin will show up in your front end and API logs, not in the admin SSO path. Confirm with your identity provider which sign-in events it retains, how long, and whether they can be exported to your monitoring tool.

Access drifts quietly after launch, so the team should review administrator and role membership on a fixed schedule set by your security policy. Compare the people who hold Super Admin and each custom role against the identity provider groups mapped to Strapi roles, and check the default role that auto-registration assigns to new accounts. Remove access that no longer matches a current job. Run the same review for end-user roles and the public permissions on the Users and Permissions plugin, because a loosened public role can expose content without any login event at all. Record the reviewer, the date and each change so the review can serve as evidence for your compliance assessor.

Plan secret rotation before it is urgent. Rotate the client secret for the identity provider application and the JWT signing material that Strapi uses for end-user tokens, using a staged window where the old and new values both work until every running instance has the new configuration. Rehearse the rotation in staging first, since a wrong value stops sign-in for everyone at once. Upgrades need the same discipline. Strapi 5 minor releases ship roughly weekly, for example v5.56.0 on September 30 and v5.57.0 on October 7, 2026, so read the release notes for authentication changes and schedule a login regression test after each upgrade. The test should cover admin SSO, the local break-glass login, end-user login, token refresh and role-based access.

Keep a local administrator account that can sign in without the identity provider, and test it on a schedule. Strapi's SSO feature can lock out local login, so confirm how your configuration handles that setting before go-live, and store the break-glass credential in a sealed location with access logged. Test that it works, confirm that each use raises an alert, and rotate its password after every test or use. Back up the database that holds users, roles and permissions, and test restores on a schedule. Strapi's migration documentation says downgrades are not supported, so a verified backup taken before each upgrade is your rollback path.

Documentation is what lets someone other than the builder recover the system at 2 a.m. Keep current records of the provider configuration, the role matrix that maps identity groups to Strapi roles and permissions, every registered redirect URI, and the location of each secret by name and owner, never by value. Add a lock-out runbook with the break-glass steps, the first checks on the provider and Strapi side, who approves emergency changes and how the incident is logged. Review these documents after each upgrade and after each access review, and confirm with your hosting and security teams where the copies live and who can read them.

Questions buyers ask before hiring help with Strapi SSO

Is SSO available on the Strapi Community Edition?

No. According to Strapi's self-hosted pricing page, SSO is an add-on for the Growth plan and is included in the Enterprise plan. Community is free, has unlimited users and is licensed under the MIT Expat license, but SSO is not listed as part of it. Confirm the current feature table on Strapi's pricing page before you budget, because plan contents can change. If your team needs admin SSO, the choice is usually between Growth with the SSO add-on and Enterprise, and the deciding factors are the other features you need, such as audit logs and review workflows, which Strapi lists under Enterprise.

How much does SSO add to the Strapi Growth plan?

The Growth plan is listed at 45 US dollars per month including 3 users, with 15 dollars per extra user, according to Strapi's self-hosted pricing page. The SSO add-on has its own charge on top of that plan, and the current figure is on the same pricing page, so check it there before you compare options. Ask Strapi how admin seats are counted against the plan. Your total recurring cost also includes your identity provider licensing, which you already pay for or will pay for separately. DeployOpen's setup work is a one-time cost agreed in a written scope, and it is separate from the Strapi subscription.

Can our own team configure Strapi admin SSO without a partner?

Yes, if one or two engineers can work in both the Strapi admin panel and your identity provider, and can test the result carefully. Strapi's SSO documentation describes the connection, auto-registration, the default role and the optional local login lock-out. The main risks are not the clicks themselves but the mistakes that lock administrators out, incorrect role mapping and unclear ownership after go-live. Hire help when no one on your team owns the identity provider settings, when several environments need the same configuration, or when a failed login would block editors during a launch window.

How long does Strapi SSO setup take, and what drives the duration?

The duration depends on the scope and the dependencies around it, and no fixed number applies to every project. The main drivers are the number of identity providers and tenants, whether you need role mapping beyond a single default role, how quickly your identity team can grant admin access and approve changes, whether a test tenant exists, how many environments need the setup (development, staging and production), and the time needed to buy the right Strapi plan. Ask for a timeline in the written scope, with each dependency named and the party responsible for it.

What does our team need to provide for a Strapi SSO project?

Most of the work depends on access and decisions from your side. Plan to provide:

Administrator access to the identity provider, or a named person who can make the changes with you
A test tenant or test users that can log in without touching production accounts
Role definitions that map your identity groups to Strapi admin roles
A staging Strapi instance that matches production configuration
A named owner who approves the design, accepts the test results and handles requests after handover
A change window for production, with a rollback plan agreed in advance

Missing any of these usually adds time, so confirm them before work starts.

Does Strapi SSO cover end users of our website or app?

No. Strapi SSO applies only to administrator login to the Strapi admin panel through an identity provider. End-user authentication for your website or app is handled separately by the Users and Permissions plugin, which can issue JWTs and connect to third-party providers for your front end. If you need both, treat them as two scopes with separate requirements, separate test plans and separate quote lines. Do not assume that enabling admin SSO also secures the public API, because public access is controlled by roles and permissions configured inside Strapi.

How do we avoid locking every Strapi administrator out during setup?

Prepare recovery access before you change anything. Keep at least one local administrator account with local login available until the SSO path has been tested end to end. Build and test the configuration on a staging instance that uses the same identity provider settings as production. Test with a second, non-owner account to confirm auto-registration and the default role behave as designed. Before you enable the optional local login lock-out, confirm that you can still reach the server, database and configuration files, so you can reverse the change if needed. Document the rollback steps and schedule the production change in a window when someone can respond quickly.

What should we ask for in a Strapi SSO quote?

Ask for a written scope that lists what is included and excluded. The scope should name the identity providers and environments covered, the Strapi plan assumed (and who buys it), the role mapping approach, the test plan and acceptance criteria, the handover documents, and the owner on each side. Check whether end-user authentication is excluded, whether identity provider licensing is your cost, and how change requests are priced. Ask what support is included after go-live and whether it is a separate retainer. DeployOpen works to fixed scopes agreed in writing before work starts, so a quote should follow directly from that scope.

How DeployOpen works on this

DeployOpen plans, builds, documents and supports self-hosted open-source platforms inside your own infrastructure, including Strapi SSO and authentication. Admin panel SSO and end-user login are scoped and built as separate pieces, so each one is tested and handed over on its own terms.

How we scope

Confirm which Strapi plan carries admin SSO, since SSO is a Growth add-on or part of Enterprise.
Record the identity provider, default admin role, and whether local login stays available as a fallback.
Define end-user login separately: Users and Permissions roles, JWT handling, and any third-party providers for your front end.

How we build

Configure admin SSO against your identity provider in a non-production Strapi environment first.
Set up auto-registration and role mapping so administrators land with the permissions your review approved.
Build and test end-user authentication flows, token lifetimes and public route permissions as one tested unit.

How we hand over

Deliver written configuration notes covering identity provider settings, role mappings and environment variables for each environment.
Document the lock-out procedure and the steps your team follows to restore admin access if the identity provider fails.
Walk your engineers through test results, rollback steps and where secrets are stored, then close the engagement in writing.

How we support

Offer ongoing support and upgrades as a retainer after handover, if your team wants continued cover.
Review authentication changes when Strapi releases or plugin updates affect the admin panel or Users and Permissions plugin.
Confirm with your identity provider vendor which SSO protocol options and provisioning features apply to your tenant before the scope is signed.

Strapi SSO and authentication