Risk Assessment: OAuth Authentication#
Risk Matrix#
Impact: High = Critical failure | Medium = Business disruption | Low = Minor issue
Likelihood: High = Likely | Medium = Possible | Low = Unlikely
Risk 1: Token Exposure Through Insecure Storage#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: OAuth2 access tokens or refresh tokens exposed through insecure storage (disk, memory dumps, logs, error messages)
Cause: - Tokens stored in plaintext without encryption - Tokens written to application logs or error traces - Memory-based storage without proper protection - Insufficient access controls on storage backends
Impact: High
Likelihood: Medium
Risk Level: Critical
Mitigation: - Azure AD client secrets stored in AWS SSM Parameter Store with encryption at rest - Token storage backend configurable (memory, disk, DynamoDB) with encryption support for persistent storage - Tokens explicitly excluded from logs and error responses (never logged or exposed in responses) - OAuth2 token transience enforced - tokens cleared from memory when sessions expire - Storage backends implement proper access controls (DynamoDB with IAM policies, disk with file permissions) - OBO flow minimizes token lifetime - tokens exchanged just-in-time for API calls
Verification: - Test: Inspect application logs for bearer tokens → expect none found - Test: Check disk storage encryption for DynamoDB and disk backends → expect encryption at rest enabled - Test: Attempt to retrieve tokens from API responses → expect tokens redacted - Test: Verify SSM Parameter Store encryption → expect KMS encryption enabled
Residual Risk: Medium
Risk 2: Unauthorized Access via Token Theft#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: Attacker intercepts or steals valid OAuth2 tokens and uses them to impersonate users and access Microsoft Graph APIs
Cause: - Man-in-the-middle attacks on token exchange - Stolen tokens from compromised client devices - Session hijacking through XSS or network interception - Missing TLS enforcement on token endpoints
Impact: High
Likelihood: Medium
Risk Level: Critical
Mitigation: - Azure AD enforces TLS 1.2+ on all OAuth endpoints - Token exchange with Microsoft (login.microsoftonline.com) uses HTTPS with certificate validation - OAuth2 tokens scoped to user's existing permissions - cannot escalate privileges - Azure AD conditional access policies enforced (MFA, trusted devices, IP restrictions) - Token expiration and refresh token rotation reduce window of opportunity - OBO flow maintains user identity and permissions through token chain
Verification: - Test: Attempt to use expired access token → expect 401 Unauthorized - Test: Verify TLS enforcement on OAuth endpoints → expect TLS 1.2+ required - Test: Attempt API call with token beyond user's permissions → expect 403 Forbidden from Graph API - Test: Verify MFA enforcement via Azure AD policies → expect MFA challenge on authentication
Residual Risk: Medium
Risk 3: Credential Theft via Phishing#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: Users tricked into entering Novo Nordisk credentials on fake Azure AD login pages, allowing attacker to obtain valid OAuth tokens
Cause: - Phishing emails with fake Azure AD login links - Spoofed authentication pages - Users not verifying domain (login.microsoftonline.com) - Social engineering targeting OAuth consent flow
Impact: High
Likelihood: Low
Risk Level: High
Mitigation: - Authentication delegated entirely to Azure AD (login.microsoftonline.com) - MCP servers do not handle credentials - Users authenticate via official Microsoft OAuth flow with recognizable Microsoft branding - Azure AD conditional access enforces device trust and network location checks - MFA enforcement reduces impact of stolen passwords - OAuth consent screen explicitly shows app name and permissions requested - User training on recognizing legitimate Azure AD login pages
Verification: - Test: Verify OAuth redirect goes to login.microsoftonline.com → expect official Microsoft domain - Test: Check MFA enforcement on authentication → expect second factor required - Test: Verify consent screen displays accurate app information → expect correct app name and permissions - Manual Review: Confirm user training materials cover OAuth phishing detection
Residual Risk: Low
Risk 4: Excessive Permission Scope Granted#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: OAuth2 scopes requested exceed principle of least privilege, granting MCP servers access to user data beyond operational requirements
Cause: - Overly broad scope requests (e.g., Files.ReadWrite.All instead of Files.Read.All) - Admin consent bypassing user review of permissions - Lack of scope validation during token exchange - Incremental scope creep without review
Impact: Medium
Likelihood: Medium
Risk Level: Medium
Mitigation: - OAuth2 scopes explicitly defined and limited to read-only operations (Mail.Read, Calendars.Read, Files.Read.All) - Offline_access scope included only for refresh token support (session continuity) - User consent required for all scopes - no admin pre-consent without user awareness - Scopes validated during OBO token exchange - Graph API tokens scoped to authenticated user's existing permissions (RBAC honored) - No write or delete scopes requested (read-only architecture)
Verification: - Code Review: Verify scope definitions in config.py → expect read-only scopes only - Test: Review Azure AD app registration permissions → expect minimal delegated permissions - Test: Attempt to perform write operation with read-only token → expect 403 Forbidden - Test: Verify user consent flow displays exact scopes requested → expect transparent permission list
Residual Risk: Low
Risk 5: Session Hijacking via Missing Token Validation#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: Attacker reuses stolen or expired tokens to maintain unauthorized access due to insufficient token validation
Cause: - Missing token expiration checks - No refresh token rotation - Lack of session revocation capability - Insufficient validation of token audience and issuer
Impact: High
Likelihood: Low
Risk Level: Medium
Mitigation: - Azure AD OAuth2 tokens include expiration claims (exp) validated by Microsoft services - Refresh tokens automatically rotated by Azure AD on use - Access tokens expire within Azure AD-defined timeframe (typically 60-90 minutes) - OBO token exchange validates token audience and issuer via Azure AD - Session termination triggers token removal from storage backend - Azure AD supports remote token revocation via user or admin action
Verification: - Test: Attempt API call with expired access token → expect 401 Unauthorized - Test: Verify token expiration enforcement by Graph API → expect time-based rejection - Test: Trigger session termination and verify tokens cleared → expect no tokens in storage - Code Review: Verify OBO implementation validates token claims → expect issuer and audience validation
Residual Risk: Low
Risk 6: Insufficient Audit Logging of Authentication Events#
Related Requirement: @URS:OAuthAuthentication
What Could Fail: Security incidents involving authentication cannot be investigated due to missing or incomplete audit logs
Cause: - Authentication events not logged - Logs missing critical details (user identity, timestamp, IP address, result) - Logs not centralized or searchable - Token values included in logs (exposing credentials)
Impact: Medium
Likelihood: Medium
Risk Level: Medium
Mitigation: - Authentication events logged with user identity, timestamp, result (success/failure) - Python logging framework used throughout codebase (logger.info, logger.error) - Logs structured for centralized aggregation (AWS CloudWatch, ELK stack) - Tokens explicitly excluded from logs (OBO implementation avoids logging bearer tokens) - Failed authentication attempts logged for security monitoring - Azure AD provides additional audit trail for OAuth consent and token issuance
Verification: - Test: Trigger authentication success → expect log entry with user identity and timestamp - Test: Trigger authentication failure → expect log entry with failure reason - Code Review: Grep codebase for token logging → expect no bearer token values in log statements - Test: Verify logs exclude sensitive data (tokens, secrets) → expect redaction in place
Residual Risk: Low
Summary Table#
| Risk ID | Description | Impact | Likelihood | Level | Mitigation | Residual |
|---|---|---|---|---|---|---|
| RISK-001 | Token exposure through insecure storage | High | Medium | Critical | SSM Parameter Store, encrypted storage, no logging, transient tokens | Medium |
| RISK-002 | Unauthorized access via token theft | High | Medium | Critical | TLS enforcement, user-scoped tokens, conditional access, token expiration | Medium |
| RISK-003 | Credential theft via phishing | High | Low | High | Azure AD delegation, MFA, device trust, user training | Low |
| RISK-004 | Excessive permission scope granted | Medium | Medium | Medium | Read-only scopes, user consent, RBAC honored, no write permissions | Low |
| RISK-005 | Session hijacking via missing token validation | High | Low | Medium | Token expiration, refresh rotation, issuer validation, session termination | Low |
| RISK-006 | Insufficient audit logging | Medium | Medium | Medium | Structured logging, centralized aggregation, no token logging, Azure AD audit trail | Low |
Version: 1.0
Date: 2025-01-24
Approved by: Pending Review
Related Artifacts:
- User Requirements: features/oauth-authentication.feature
- Intended Use: docs/requirements/01-intended-use.md