Auth & Access
This section defines EGI's standards for authentication, authorization, and access control across all projects and internal systems. These standards apply to every application EGI builds, every service we operate, and every project we hand off to Anchor MSP for ongoing management.
Why This Matters
Authentication and access control are foundational to every system EGI delivers. A poorly implemented auth system creates security vulnerabilities, compliance risks, and operational headaches for Anchor when they take over management. Getting auth right from the start saves significant time and reduces risk across the entire lifecycle.
Core Principles
Defense in Depth
Never rely on a single layer of security. Every system should implement multiple, overlapping controls:
- Network layer: Firewalls, rate limiting, IP allowlisting where appropriate
- Application layer: Authentication (who are you?), authorization (what can you do?), input validation
- Data layer: Encryption at rest, encrypted connections, minimal data exposure
- Monitoring layer: Audit logs, anomaly detection, alerting
If one layer fails, the others should still protect the system.
Least Privilege
Every user, service account, and API key should have the minimum permissions required to perform its function:
- Do not grant admin access when read access is sufficient
- Do not use a single "super admin" API key across multiple services
- Scope tokens and keys to specific resources and actions
- Review and revoke unused permissions regularly
Secure by Default
New systems, accounts, and configurations should default to the most restrictive settings:
- New user accounts start with no permissions; access is granted explicitly
- API endpoints require authentication unless there is a documented reason for public access
- Environment variables and secrets are never committed to version control
- HTTPS is required for all communication; HTTP is never acceptable in production
Separation of Concerns
Authentication (identity verification) and authorization (permission enforcement) are separate concerns and should be implemented as separate layers:
- Authentication confirms the user is who they claim to be
- Authorization determines what the authenticated user is allowed to do
- Changes to one layer should not require changes to the other
Standards Overview
| Area | Standard | Details |
|---|---|---|
| User authentication | OAuth 2.0 / OIDC preferred | See Auth Patterns |
| API authentication | API keys or JWT | See Auth Patterns |
| Access control | Role-based (RBAC) | See Access Expectations |
| MFA | Required for all internal services | See Access Expectations |
| Account provisioning | Named accounts, no shared logins | See Account Provisioning |
| Documentation | Auth must be documented for handoff | See Documenting Auth |
| Future direction | SSO and centralized identity | See Future Planning |
Section Contents
- Auth Patterns -- OAuth 2.0, API keys, JWT, session-based auth, and NextAuth.js implementation patterns
- Access Expectations -- Named accounts, least privilege, MFA, and quarterly access reviews
- Documenting Auth -- Authentication documentation templates for Anchor handoff
- Account Provisioning -- Creating accounts, naming conventions, and the access matrix
- Future Planning -- SSO roadmap, identity provider evaluation, and centralized access goals
Applicability
These standards apply to:
- All client-facing applications built by EGI
- All internal tools and services
- All integrations with third-party services
- All projects being prepared for Anchor MSP handoff
Exceptions must be documented with a clear justification and approved by the project lead.