RFC: Compliance & Certification (SOC 2, GDPR, HIPAA, OIDC)

[lakhansamani]

RFC: Compliance & Certification (SOC 2, GDPR, HIPAA, OIDC)

Phase: 6 — Developer Experience & Polish
Priority: P2 — Medium
Estimated Effort: Medium

---

Problem Statement

Enterprise customers require compliance certifications before adopting an auth platform. Authorizer needs to enable (not necessarily certify — that's the deployer's responsibility) SOC 2, GDPR, and HIPAA compliance through its feature set. Additionally, official OpenID Certification would validate OIDC conformance. The features from Phases 1-5 provide most building blocks — this RFC closes the remaining gaps.

---

Proposed Solution

1. GDPR Compliance Features

Data Export — Right of Access (Article 15):

type Mutation {
    # User can export all their data
    export_my_data: DataExport!
    
    # Admin can export any user's data
    _export_user_data(user_id: ID!): DataExport!
}

type DataExport {
    user: User!
    sessions: [Session!]!
    audit_logs: [AuditLog!]!
    api_keys: [APIKey!]!
    webauthn_credentials: [WebAuthnCredential!]!
    organization_memberships: [OrganizationMember!]!
    delegation_grants: [DelegationGrant!]!
    login_attempts: [LoginAttempt!]!
    export_url: String              # Download link for large exports (signed URL, 1hr TTL)
}

Right to Deletion (Article 17):

type Mutation {
    # User requests account deletion
    delete_my_account(password: String!): Response!
    
    # Admin deletes user (already exists: _delete_user)
}

Deletion process:

1. Verify identity (password or active session)
2. Revoke all sessions and tokens
3. Delete all user data: sessions, API keys, WebAuthn credentials, org memberships
4. Anonymize audit logs (replace user identifiers with "deleted_user", keep event metadata)
5. Remove user record
6. Audit log: user.data_deleted (with anonymized reference)

Consent Tracking:

type UserConsent struct {
    ID          string `json:"id" gorm:"primaryKey;type:char(36)"`
    UserID      string `json:"user_id" gorm:"type:char(36);index"`
    ConsentType string `json:"consent_type" gorm:"type:varchar(50)"`   // terms_of_service | privacy_policy | marketing | data_processing
    Version     string `json:"version" gorm:"type:varchar(20)"`        // policy version consented to
    GrantedAt   int64  `json:"granted_at" gorm:"autoCreateTime"`
    RevokedAt   int64  `json:"revoked_at"`                              // 0 if active
    IPAddress   string `json:"ip_address" gorm:"type:varchar(45)"`
}

Data Residency: Already supported via self-hosting + database-agnostic architecture. Document deployment patterns for EU-only hosting.

2. SOC 2 Type 2 Enablement

SOC 2 requires controls around:

Control Area	Authorizer Feature
Access Controls	RBAC, Fine-Grained Permissions (#508), MFA, Session Management (#507)
Audit Logging	Structured Audit Logs (#505), Log Streaming (#522)
Encryption	JWT signing (RS/ES), AES session encryption, bcrypt passwords, TLS (deployment)
Monitoring	Prometheus Metrics (#506), Health Endpoints
Incident Response	Rate Limiting (#501), Account Lockout, IP Blocking
Change Management	Audit log captures all config changes

Additional for SOC 2:

• Password policy documentation: Generate password policy report from config (min length, complexity, leaked password check status)
• Access review report: GraphQL query to export all users with their roles and last login date
• Configuration audit: Audit log captures admin.config_changed events

type Query {
    # Generate compliance report data
    _compliance_report(type: String!): ComplianceReport!  # type: soc2 | gdpr | hipaa
}

type ComplianceReport {
    generated_at: Int64!
    password_policy: Map
    mfa_status: Map                  # users with/without MFA
    role_summary: [RoleSummary!]!    # role → user count
    active_sessions_count: Int!
    audit_log_retention_days: Int!
    encryption_config: Map           # JWT algo, session encryption
}

3. HIPAA Compliance Enablement

HIPAA (healthcare) requires:

Requirement	Authorizer Feature
Access Control (§164.312(a))	Authentication, RBAC, FGA
Audit Controls (§164.312(b))	Audit Logs, Log Streaming
Integrity Controls (§164.312(c))	Immutable audit logs
Transmission Security (§164.312(e))	TLS (deployment), DPoP (#520)
Person Authentication (§164.312(d))	MFA, Passkeys
Session Management	Session limits, auto-timeout, remote revocation

Additional for HIPAA:

• Auto session timeout: --session-idle-timeout=15m — invalidate session after inactivity
• Emergency access procedure: Admin impersonation with mandatory reason logging
• BAA readiness: Documentation for deployers on configuring Authorizer for HIPAA

4. OpenID Certification

After OIDC Provider (#514) is implemented, pursue official OpenID Certification:

Certification profiles to target:

1. Basic OP — core OIDC flows
2. Config OP — discovery document compliance
3. Dynamic OP — dynamic client registration

Steps:

1. Run OpenID Foundation conformance test suite against Authorizer
2. Fix any failing tests
3. Submit results to OpenID Foundation
4. Publish certification on authorizer.dev

Test suite: OpenID Connect Conformance Suite

---

CLI Configuration Flags

--enable-data-export=true                  # Enable user data export
--enable-account-deletion=true             # Enable self-service account deletion
--audit-log-anonymize-on-delete=true       # Anonymize audit logs on user deletion
--session-idle-timeout=0                   # Auto-expire idle sessions (0 = disabled)
--consent-tracking=false                   # Enable consent tracking

---

Testing Plan

• Test data export includes all user data across all tables
• Test account deletion removes/anonymizes all data
• Test consent tracking records and retrieves consents
• Test compliance report generation
• Test session idle timeout
• Run OpenID Conformance Suite (after RFC: Authorizer as Full OIDC Provider #514)

---

References

• GDPR Articles
• SOC 2 Compliance
• HIPAA Security Rule
• OpenID Certification
• OpenID Conformance Suite