Last modified by Agnease on 2026/05/23 18:56

From version 1.13
edited by Agnease
on 2026/05/22 03:37
Change comment: There is no comment for this version
To version 1.12
edited by Agnease
on 2026/05/22 03:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -35,21 +35,20 @@
35 35   <h2 id="overview-title">Stronger login protection for XWiki</h2>
36 36  
37 37   <p>
38 - The XWiki MFA / Two-Factor Authentication extension adds additional verification after the standard
39 - XWiki username and password login. It strengthens account protection without replacing the familiar
40 - XWiki authentication flow.
38 + The XWiki Two-Factor Authentication extension adds an additional verification screen after the standard
39 + username and password login. Users confirm their identity with a time-based one-time code generated by an
40 + authenticator app, or with a verification code delivered by email.
41 41   </p>
42 42  
43 43   <p>
44 - The extension supports authenticator app codes using TOTP, email-delivered one-time verification codes,
45 - and stricter configurations where both verification methods are required. This allows organizations to
46 - choose between a simpler 2FA setup or a stronger multi-step MFA policy.
44 + The extension is designed for organizations that want to improve account security while keeping authentication
45 + close to the standard XWiki login experience. It also supports remembering trusted clients beyond the current
46 + session, so users are not forced to enter a second factor again on every login from the same trusted browser.
47 47   </p>
48 48  
49 49   <p>
50 - Trusted clients can also be remembered for a configured period. In practice, this means that a known
51 - browser or device can avoid repeated MFA prompts, while new or untrusted clients still require the
52 - configured verification steps.
50 + It can be useful for internal knowledge bases, intranets, documentation platforms, SOP systems, or other
51 + XWiki environments where access to content and administration should be better protected.
53 53   </p>
54 54   </article>
55 55