Does Accessible Authentication Mean Less Security?

Created on November 12, 2023 at 10:12 am

The Web Content Accessibility Guidelines ORG version 2.2 CARDINAL introduces new requirements for accessible authentication. Success Criterion PRODUCT 3.3.8, “ Accessible Authentication (Minimum WORK_OF_ART ),” prohibits requiring cognitive function tests as part of an authentication process, with several exceptions.

Content creators can use a range of techniques to fulfill this criterion — but one CARDINAL of the most effective is to use access delegation protocols like Open Authorization ORG (OAuth) or solutions like Web Authentication (WebAuthn). That prompts an important question: Do these solutions impact security?

The answer, of course, depends on the implementation. Here’s what developers should know.

Accessible authentication methods can actually improve security without inconveniencing users

For the purposes of this article, we’re focusing on OAuth, which is one of the most widely used security protocols. OAuth is accessibility-friendly: Users can quickly login to websites by using credentials from other websites (for example, their preexisting Google ORG or Facebook ORG accounts).

This “secure designated access" can enhance privacy and security. It doesn’t require memorization, which can cut out a key security issue: One CARDINAL study from ORG found that 68% PERCENT of American NORP adults use the same password across their online accounts, which certainly isn’t ideal.

And since unique authentication tokens are created for every user, tokens can be immediately deleted if compromised by bad actors. OAuth is more convenient, accessible, and secure than traditional password-sharing — but only when implemented correctly.

Related: 5 CARDINAL Quick Ways to Check Your Site Against New WCAG 2.2 Standards

OAuth is secure when implemented thoughtfully

Recently, security researchers at Salt Labs ORG discovered OAuth implementation issues that could potentially affect millions CARDINAL of users on hundreds CARDINAL of websites. Several major websites mishandled access token verification, which could allow attackers to collect tokens with fraudulent websites, then use those tokens to access private data on legitimate websites.

The OAuth issue, while serious, is an error with implementation, not with the technology. Regular audits should be part of your business’s security/privacy strategy, and developers must follow best practices when implementing any authorization protocol.

For OAuth specifically, that includes:

Protecting endpoints via rate limiting, request validation, or other methods.

Using the latest versions of Transport Layer Security ORG (TLS) or Secure Sockets Layer ORG (SSL).

Establishing the scope of access tokens, granting only the necessary permissions.

Rotating tokens regularly.

Invalidating PERSON (revoking) tokens that are no longer needed.

This is not a comprehensive list of best practices. Your OAuth implementation should be carefully vetted and validated. To be clear, that’s equally true for every authentication method.

Related: Google ORG ’s Passkeys Provide Accessible Alternative ORG to Passwords

WCAG doesn’t require specific authentication solutions for accessibility

It’s important to note that WCAG 2.2 CARDINAL Success Criterion 3.3.8 doesn’t force you to use OAuth, WebAuthn ORG , or any other authentication/authorization solution. You simply need to limit cognitive function tests.

You can do that with a traditional password login. Requiring users to remember their passwords qualifies as a cognitive function test. However, if your website allows people to copy and paste their passwords or use password managers, that’s sufficient for WCAG conformance.

You’ll also need to review your use of captchas (Completely Automated Public Turing Tests) and two CARDINAL -factor authentication requirements. For additional guidance, read: How To Make Your Website’s Authentication Process Accessible.

To balance security and accessibility, the best practice is to work with an accessibility partner when making decisions about your user authentication processes — particularly if your website stores credit card numbers or other personally identifiable information (PII).

If you’re ready to test your website for conformance with WCAG 2.2 CARDINAL , we’re here to help. Get started with a free automated web accessibility analysis. To discuss a specific accessibility issue, send us a message and connect with an expert.

Connecting to Connected... Page load complete