Intranet Cross-Domain Authentication

TL;DR

Cross-domain authentication in an intranet is tricky because browsers block direct access to cookies from different domains (even within the same organisation). The best approach depends on your setup, but using a central Identity Provider (IdP) with Single Sign-On (SSO) and techniques like CORS or a reverse proxy are common solutions. This guide covers several options.

Understanding the Problem

When applications run on different subdomains (e.g., app1.example.com and app2.example.com) or even different ports, browsers treat them as separate origins for security reasons. This means cookies set by one application aren’t automatically available to the other.

Solutions

1. Central Identity Provider (IdP) with SSO
• This is generally the best long-term solution.
• Implement a central authentication service (e.g., using Keycloak, Okta, Azure AD).
• All applications redirect to the IdP for login.
• The IdP issues tokens (like JWTs) that applications can use to verify user identity.
• Applications don’t directly handle usernames/passwords.
2. CORS (Cross-Origin Resource Sharing)
• Allows specific origins to access resources from another origin.
• Configure your authentication server to send the correct CORS headers in its responses.
• Example header: Access-Control-Allow-Origin: * (allows all, use with caution!) or Access-Control-Allow-Origin: https://app1.example.com (allows only app1).
• The requesting application must handle the preflight OPTIONS request.
3. Reverse Proxy
• A reverse proxy sits in front of your applications and handles authentication.
• All requests go through the proxy, which verifies the user’s identity.
• The proxy then forwards authenticated requests to the appropriate application.
• This hides the complexity of cross-domain authentication from the applications themselves.
• Example using Nginx:

  
  server {
      listen 80;
      server_name app1.example.com;
  
      location / {
          proxy_pass http://backend_app1:3000;
          proxy_set_header Host $host;
          # Add authentication logic here (e.g., basic auth, token validation)
      }
  }
  

4. PostMessage API
• Allows secure communication between different origins.
• One application sends a message to another, which can then respond with authentication information.
• More complex to implement and requires careful security considerations.
5. Document Domain (Generally Discouraged)
• Setting document.domain = 'example.com' in both applications can allow them to share cookies.
• Security risk! This weakens security and is not recommended unless absolutely necessary. It’s best avoided.

Implementation Steps (CORS Example)

1. Configure your Authentication Server: Add the Access-Control-Allow-Origin header to all authentication responses.
2. Client-Side Code: Make sure your client-side code handles CORS preflight requests correctly.

   
   fetch('https://auth.example.com/login', {
     method: 'POST',
     mode: 'cors',
   })
   .then(...)
   

3. Testing: Verify that your applications can successfully authenticate and access resources across domains. Use browser developer tools to check for CORS errors.

Security Considerations

• Always use HTTPS.
• Validate all input data.
• Protect against Cross-Site Request Forgery (CSRF) attacks.
• Regularly review and update your security configuration.