SSO
SSO allows access to multiple services using a shared authentication mechanism. It can reduce login difficulties and centralize certain security policies. It does not replace application-specific permissions. Rights, exits, and role changes must still be managed.
A concrete example
A member already logged into their main account accesses the programme without a new password. The platform verifies an assertion or a token, depending on the chosen integration.
A point to consider
Successful authentication does not prove eligibility for the programme. Identity, access rights, and session termination remain separate.
Test the account lifecycle.
Document the first login, the recognition of an existing account, and the termination of access rights. Test a deactivated account, a change of role, and an expired session. Provide a clear message and support when an authenticated user is ineligible. Successful integration is also verified by examining these refusal situations and the consistency of disconnections.
Questions to ask your team
- How does a deactivation become effective in the programme?
- Does a role change update permissions without creating a second account?

