fix(cors): Allow Bearer token authentication for CORS requests

[cbcoutinho]

Fix Bearer Token Authentication for CORS Endpoints

Problem

Bearer token authentication with OAuth 2.0/OIDC currently fails for app-specific APIs (Notes, Calendar, Contacts, etc.) with 401 Unauthorized errors, even though the same Bearer tokens work correctly for OCS APIs.

Root Cause

When using Bearer token authentication with CORS-annotated endpoints:

1. ✅ Bearer token validation successfully authenticates the user
2. ✅ A session is created for the authenticated user
3. ❌ CORSMiddleware detects the logged-in session but no CSRF token
4. ❌ CORSMiddleware calls session->logout() to prevent CSRF attacks
5. ❌ The logout invalidates the session, breaking the API request with 401

This occurs because app-specific APIs (Notes, Calendar, etc.) use the #[CORS] attribute, which triggers CORSMiddleware security checks. OCS APIs don't have this attribute and handle Bearer tokens correctly via SecurityMiddleware::isValidOCSRequest() (lines 234-237).

Error Manifestation

CORS requires basic auth (401 Unauthorized)

Or in logs:

[TokenInvalidatedListener] Could not find the OIDC session related with an invalidated token
Session token invalidated before logout
Logging out

Solution

This PR extends CORSMiddleware to accept Bearer token authentication without requiring CSRF tokens, aligning with the existing pattern used by SecurityMiddleware for OCS routes.

Changes

lib/private/AppFramework/Middleware/Security/CORSMiddleware.php

• Added check for Authorization: Bearer header before CSRF and app_api checks
• Bearer-authenticated requests now bypass session logout logic
• Maintains backward compatibility with existing authentication flows

tests/lib/AppFramework/Middleware/Security/CORSMiddlewareTest.php

• Added testCORSShouldAllowBearerAuth() test to verify Bearer tokens are accepted
• Ensures no session logout occurs for Bearer-authenticated requests

Implementation Details

// Allow Bearer token authentication for CORS requests
// Bearer tokens are stateless and don't require CSRF protection
$authorizationHeader = $this->request->getHeader('Authorization');
if (!empty($authorizationHeader) && str_starts_with($authorizationHeader, 'Bearer ')) {
    return;
}

This check is placed before the CSRF token and app_api checks to allow Bearer tokens to bypass session-based security requirements.

Security Considerations

Why is this safe?

1. Stateless Authentication: Bearer tokens are inherently stateless and don't rely on cookies or sessions
2. CSRF Protection Not Needed: CSRF attacks target session-based authentication; Bearer tokens are immune as they're sent explicitly via headers
3. Existing Pattern: SecurityMiddleware already allows Bearer tokens for OCS endpoints (line 234-237)
4. OAuth 2.0 Standard: Bearer token usage is a standard OAuth 2.0 pattern for API authentication

What doesn't change?

• Session-based authentication still requires CSRF tokens
• Basic Auth still works as before
• AppAPI authentication (app_api flag) still works
• Public pages maintain existing behavior

Backward Compatibility

✅ Fully backward compatible

• Existing CSRF token authentication continues to work
• Basic Auth (PHP_AUTH_USER/PHP_AUTH_PW) continues to work
• AppAPI authentication continues to work
• Only adds a new authentication path without modifying existing flows

Related Issues & PRs

• Fixes: [Bug]: "CORS requires basic auth" error when authenticating with OIDC token #44365
• Related: Does the user_oidc application support notes and other non-OCS API endpoints? user_oidc#836
• Related: Fix Bearer token authentication for non-OCS endpoints user_oidc#1221

Configuration

No configuration changes required. Works automatically with any authentication backend that provides Bearer tokens via the Authorization header:

• user_oidc app with Bearer token validation
• OAuth2 apps
• Custom authentication backends
• AppAPI external apps (still supported via existing app_api flag)

Documentation Impact

No documentation changes required. This fix makes Bearer token authentication work as users would naturally expect, aligning with OAuth 2.0 best practices.

---

Checklist

• Implementation follows existing patterns in SecurityMiddleware
• Tests added for new functionality
• Backward compatibility maintained
• Security considerations addressed
• Related issues linked
• Commit message follows Nextcloud conventions

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[cbcoutinho]

Hi @ArtificialOwl @Altahrim @sorbaugh - friendly ping. Could you possibly review this PR?

[DaphneMuller]

@oleksandr-nc @nickvergessen @blizzz @juliusknorr any chance some of you can review this pr?