Authentifizierung
SecureCodingHub unterstützt mehrere Authentifizierungsmethoden. Browser-Sitzungen verwenden JWT-Bearer-Tokens; die öffentliche API verwendet langlebige API-Schlüssel mit scope-basierter Autorisierung und Pro-Schlüssel-Rate-Limits.
Authentifizierungsmethoden
Wählen Sie die Authentifizierungsmethode, die am besten zu Ihrer Organisation passt:
Magic Code (E-Mail OTP)
Passwortlose Anmeldung über 6-stelligen Code per E-Mail. Standardmethode für alle Benutzer. Codes laufen nach 10 Minuten ab. Kein Passwort zu verwalten oder zu merken.
OIDC (OpenID Connect)
Enterprise SSO über Azure AD, Okta oder kompatible Anbieter. Authorization Code Flow mit PKCE. Empfohlen für Organisationen.
SAML 2.0
Föderations-basiertes SSO für Unternehmensumgebungen. SP-initiierter Anmeldevorgang.
Magic Code Ablauf
Der standardmäßige passwortlose Authentifizierungsablauf funktioniert wie folgt:
Benutzer gibt seine E-Mail-Adresse ein
Server sendet einen 6-stelligen OTP an die E-Mail
Benutzer gibt den Code ein
Server verifiziert den Code und stellt ein JWT aus
JWT wird im Browser für die Sitzungsverwaltung gespeichert
SSO-Ablauf
Wenn SSO für Ihre Organisation konfiguriert ist, ändert sich der Authentifizierungsablauf:
Benutzer öffnet den SSO-Einstiegspunkt für seine Organisation (der Link enthält den Organisations-Slug; es gibt heute keine automatische E-Mail → Domain-Erkennung)
Browser leitet zum konfigurierten Identitätsanbieter weiter
Benutzer authentifiziert sich mit Unternehmensanmeldedaten
IdP gibt einen Autorisierungscode (OIDC) oder eine SAML-Behauptung an den SecureCodingHub-Callback zurück
Server validiert die Antwort, stellt den Benutzer bei der ersten Anmeldung über JIT bereit und gibt ein JWT aus
Benutzer ist angemeldet
JWT-Tokens
Alle browser-orientierten authentifizierten Sitzungen werden mit JSON Web Tokens verwaltet, die vom Backend nach erfolgreichem Magic-Code- oder SSO-Schritt ausgestellt werden.
| Eigenschaft | Wert |
|---|---|
| Algorithmus | HS256 |
| Lebensdauer | 30 Tage ab Ausstellung. Es gibt keinen In-App-Refresh-Ablauf; Benutzer authentifizieren sich erneut über Magic Code oder SSO, sobald das Token abläuft. |
| Claims | Benutzer-ID, Organisations-ID, Rolle, Name, E-Mail, Ablauf. |
| Übertragung | Authorization: Bearer …-Header bei jedem internen API-Aufruf. |
| Speicher | Clientseitig gespeichert in localStorage unter dem sch-token-Schlüssel. Es gibt heute keine HttpOnly-Cookie-Option. |
API-Schlüssel Bearer (Öffentliche API)
Die öffentliche REST- und Webhook-Oberfläche unter /api/public/v1/* verwendet langlebige API-Schlüssel anstelle von JWTs. Schlüssel werden in der Administratorkonsole unter Organisation → API-Schlüssel erstellt und bei jeder Anfrage als standardmäßiger Bearer-Header gesendet:
Authorization: Bearer scs_live_…| Eigenschaft | Wert |
|---|---|
| Format | scs_live_ + 32 zufällige base62-Zeichen. 41 Zeichen insgesamt. |
| Speicher | Nur der SHA-256-Hash, das Präfix und die letzten vier Zeichen werden auf dem Server aufbewahrt. Das vollständige Token wird einmal bei der Erstellung angezeigt und kann nicht erneut abgerufen werden. |
| Scopes | 16 feingranulare Scopes (z.B. users:read, assignments:write, sarif:ingest). Eine Anfrage ohne den erforderlichen Scope gibt 403 insufficient_scope zurück. |
| Lebensdauer | Standardmäßig unbegrenzt. Ein optionales Ablaufdatum kann zum Erstellungszeitpunkt festgelegt werden. Schlüssel können jederzeit widerrufen werden; der Widerruf wird sofort wirksam. |
| Last-Used-Tracking | Jeder erfolgreiche Aufruf aktualisiert das lastUsedAt-Feld des Schlüssels für Audit und Rotationshygiene. |
Vollständige Referenz unter API → Authentifizierung und Scopes.
Rate Limiting
Jeder öffentliche API-Schlüssel wird durch zwei gleitende Fenster begrenzt, die die Plattform vor außer Kontrolle geratenen Skripten schützen und verhindern, dass ein Tenant einen anderen aushungert:
| Fenster | Limit | Antwort-Header |
|---|---|---|
| Pro Minute | 60 Anfragen | Retry-After, X-RateLimit-Window: per_minute, X-RateLimit-Limit: 60 |
| Pro Stunde | 1.000 Anfragen | Retry-After, X-RateLimit-Window: per_hour, X-RateLimit-Limit: 1000 |
Anfragen, die eines der Fenster überschreiten, erhalten 429 rate_limited mit einem Retry-After-Header in Sekunden. Ein separater IP-basierter Limiter (5 Anfragen / 15 Minuten) deckt das anonyme Web-Kontaktformular ab. Interner Browser-Sitzungsverkehr gegen die JWT-geschützte Administrator-API ist heute nicht rate-limited.
Detaillierte Wiederholungsanleitung und ein Beispiel-Exponential-Backoff-Client unter API → Rate Limits.
Audit-Logging
Jede mutierende Aktion — egal, ob sie von einem Administrator-Benutzer im Browser oder von einem öffentlichen API-Schlüssel stammt — wird in einer Pro-Organisation-Audit-Protokoll-Tabelle festgehalten. Schreibgeschützte Aktionen (Liste, Get, Dashboard-Abfragen) werden nicht auditiert; der Fokus liegt auf Änderungen, die nachgelagerte Auswirkungen haben.
| Feld | Bedeutung |
|---|---|
action | Punktbezeichner für das, was passiert ist (z.B. user.updated, assignment.created, apikey.revoked, sarif.ingested). |
actorEmail / actorRole | E-Mail und Rolle des Akteurs. Administrator-UI-Mutationen tragen die E-Mail des Menschen und org_admin. API-Schlüssel-Mutationen tragen apikey:<api-key-uuid> und die Rolle api_key. |
targetType, targetId, targetLabel | Die geänderte Ressource. Der Bezeichner ist eine kurze menschenlesbare Beschreibung, die in der Audit-Protokoll-UI verwendet wird. |
metadata | JSON-serialisierter Kontext, der genau beschreibt, was sich geändert hat (z.B. die neuen Scopes auf einem API-Schlüssel, die Frist vor vs. nach einer Zuweisung). |
ipAddress | Die Quell-IP der Anfrage, die die Änderung verursacht hat. |
createdAt | UTC-Zeitstempel. |
Der vollständige Audit-Stream kann aus der Administrator-UI (Organisation → Audit-Protokoll) oder programmatisch über GET /api/public/v1/audit-log abgefragt werden. Beide Oberflächen unterstützen das Filtern nach Aktion, Akteur und Datumsbereich, und die Administrator-UI bietet einen CSV-Export für Nachweispakete.
Sitzungssicherheit
- Tokens werden bei jeder API-Anfrage validiert
- Ungültige oder abgelaufene Tokens werden abgelehnt
- SSO-Sitzungen respektieren IdP-Sitzungsrichtlinien
- Magic Codes sind einmalig verwendbar und zeitlich begrenzt
Authentifizierungs-Design-Entscheidungen, die SecureCodingHub getroffen hat, und warum
Der standardmäßige Authentifizierungspfad in SecureCodingHub ist passwortlos. Wir haben diese Entscheidung bewusst getroffen. Die überwiegende Mehrheit der Anmeldedaten-Kompromittierungen, die wir in Kundenschulungsdaten sehen, lässt sich immer noch auf Passwort-Wiederverwendung, schwache Passwortwahl und Phishing statischer Secrets zurückführen. Das Entfernen des Passworts aus dem primären Anmeldevorgang eliminiert eine Klasse von Fehlermodi, die keine Richtlinie vollständig mildern kann. Für Organisationen, die einen traditionellen Passwort-Fallback erfordern, erzwingen wir Mindestanforderungen, die mit den aktuellen NIST-Richtlinien übereinstimmen: eine Längenuntergrenze statt eines Komplexitäts-Regelsatzes, das Filtern gegen bekannte kompromittierte Passwort-Sammlungen und keine erzwungene Rotation ohne Beweise für eine Kompromittierung.
E-Mail-basierte Wiederherstellung wird bewusst auch für SSO-gestützte Konten beibehalten. Wenn ein Identitätsanbieter nicht erreichbar wird oder wenn der Eintrag eines Vertragspartners im Unternehmensverzeichnis mitten in einem Engagement entfernt wird, benötigen wir dennoch einen deterministischen, auditierbaren Pfad zurück zum Konto für den verifizierten Eigentümer. Der Wiederherstellungskanal ist rate-limited, einmalig verwendbar und separat vom standardmäßigen Anmelde-Ereignisstrom protokolliert, sodass Sicherheitsteams anormale Wiederherstellungsaktivitäten erkennen können, ohne dass sie im normalen Anmelderauschen verloren gehen.
Geteilte Konten werden auf Produktebene entmutigt, anstatt direkt blockiert. Wir zeigen eine Warnung in der Administratorkonsole, wenn Nutzungsmuster darauf hindeuten, dass ein einzelner Sitzplatz zwischen mehreren Menschen geteilt wird, weil geteilte Sitzplätze die individuelle Verantwortlichkeit brechen, das Fortschritts-Reporting verzerren und jede zukünftige Vorfalluntersuchung erschweren. Organisationen, die teamübergreifenden Zugang zu Dashboards benötigen, sollten Rollenzuweisung und die in Datensicherheit beschriebenen SCIM-bereitgestellten Lernender-Rollen verwenden, anstatt Anmeldedaten wiederzuverwenden.
Authentifizierung auf Compliance abbilden
SecureCodingHub bereitet sich auf SOC 2 Type II vor und hat noch kein Audit abgeschlossen, daher beanspruchen wir keine Zertifizierung. Wir entwerfen jedoch das Authentifizierungs-Subsystem gegen dieselben Kontrollfamilien, die ein Sicherheitsteam erwarten würde, wenn es einen Anbieter für dieses Audit bewertet. SOC 2 CC6.1-Erwartungen rund um logischen Zugriff — eindeutige Identifizierung jedes Benutzers, Multi-Faktor oder gleichwertige Stufenerhöhung für sensible Aktionen und Widerruf bei Beendigung — werden durch Pro-Benutzer-Konten, den Magic Code oder die vom IdP ausgestellten Anmeldedaten als zweiten Faktor und SCIM-getriebene Deprovisionierung adressiert.
ISO 27001 Annex A.9-Kontrollen, die Zugriffskontrollrichtlinie, Benutzerregistrierung und privilegierten Zugriff abdecken, werden durch dokumentierte Rollendefinitionen, organisationsspezifische Registrierung, die auf verifizierte Domains beschränkt ist, wo gewünscht, und die explizite org_admin / learner Rollenaufteilung innerhalb jedes Tenants adressiert. Für Organisationen, die PCI DSS Abschnitt 8 unterliegen, ist die relevante Kontrolle, dass wir niemals Karteninhaberdaten speichern und Karteninhaber niemals gegen die Plattform authentifizieren; SecureCodingHub ist eine Schulungsumgebung, keine Zahlungsumgebung, daher ist die Oberfläche, auf die PCI angewendet wird, absichtlich eng.
Nichts davon sollte als Ersatz für Ihre eigene Bewertung gelesen werden. Nachweispakete, einschließlich Subprozessor-Listen, Datenflussdiagrammen und aktueller Audit-Lage, sind auf Anfrage von security@securecodinghub.com erhältlich.
Was sich ändert, wenn SSO aktiviert ist
Das Aktivieren von SSO ist nicht nur ein Tausch eines Anmeldebildschirms gegen einen anderen — es ändert mehrere Laufzeitverhalten, die Sicherheitsteams vor dem Rollout verstehen sollten. Sobald Ihre Organisation mit einem Identitätsanbieter verbunden ist, wird der lokale Magic-Code-Pfad für Benutzer, deren E-Mail Ihrer verifizierten Domain entspricht, nicht mehr angeboten. Sie werden stattdessen zu Ihrem IdP umgeleitet. Dies ist der richtige Standard, bedeutet aber, dass die Wiederherstellung während eines IdP-Ausfalls vollständig auf Ihr IT-Team übergeht, anstatt auf den SecureCodingHub-Support. Wir empfehlen, diesen Eskalationsweg intern zu dokumentieren, bevor Sie SSO für eine große Benutzerbasis einschalten.
Auch das Sperrverhalten verschiebt sich: Rate-limited fehlgeschlagene Versuche auf dem lokalen Magic-Code-Pfad gelten für denselben Benutzer nicht mehr, sobald SSO in Kraft ist, weil die gesamte Anmeldedaten-Validierung beim IdP geschieht. Die Sperrrichtlinie wird dann von Ihrer IdP-Konfiguration und nicht von SecureCodingHub-Standards gesteuert. Audit-Protokoll-Einträge, die von Mutationen geschrieben werden, die der Benutzer nach der Anmeldung durchführt, tragen weiterhin die E-Mail des Benutzers und die Rolle org_admin / learner; die Plattform speichert derzeit nicht die IdP-seitige Authentifizierungsmethode (z.B. ob MFA beim IdP erfüllt wurde) in der Audit-Zeile, daher würden Sie für dieses Detail mit dem eigenen Protokollstream Ihres zentralen Identitätsanbieters korrelieren.