Authentication
What the exam tests
Authentication on OutSystems separates IT users from end users. IT users sign in to LifeTime and Service Center to build, deploy, and operate apps. End users sign in to the applications you build; their identities live in the Users application and are managed per environment. The exam expects you to choose the right provider and know where each setting lives.
Core rules
- Built-in authentication stores end-user credentials in the platform. Passwords are hashed by the platform; you should not build your own password table.
- External authentication is configured in the Users application: Active Directory/LDAP, SAML 2.0, or OpenID Connect. The identity provider authenticates; OutSystems maps claims or attributes to the user record.
- Plan provisioning. Users can be created ahead of time or created on first login; decide how roles and groups are assigned so a new user does not arrive with excessive access.
- Session settings such as timeout and persistent login are environment-level controls. Treat them as security settings, not convenience defaults.
- MFA is normally an identity-provider capability. Do not assume that enabling external authentication automatically adds a second factor.
Worked example
A company wants employees to use corporate credentials. The team configures SAML 2.0 in the Users application, maps the email claim to the platform username, and assigns module roles through groups synchronized from the directory. They do not create a custom login screen with a password entity. Reasoning: the IdP owns credential verification, MFA, and password policy; OutSystems owns authorization after authentication.
Traps
- Configuring end-user authentication in LifeTime instead of the Users application.
- Leaving built-in authentication enabled after cutover, creating a bypass path.
- Hardcoding IdP secrets in code or plain site properties.
- Testing only in Development; authentication settings are per environment.