Zurück zur Übersicht

Credential-Service – Zugriffe zentral & sicher managen, auch außerhalb der Microsoft-Welt

In vielen Unternehmen ist die IT-Landschaft historisch gewachsen: Moderne Microsoft-365-Dienste stehen neben spezialisierten Dritttools, Legacy-Systemen und SaaS-Anwendungen, die nur einfache Authentifizierungsverfahren (API-Key, Basic Auth) kennen. Für Mitarbeitende bedeutet das ständige Kontextwechsel und wiederkehrende Logins – ein Reibungsverlust, der Produktivität kostet und zu unsicheren Workarounds führt. Zugangsdaten landen im Clientcode, in Konfigurationsdateien, in Git-Repos oder, schlimmer noch, auf Post-its unter der Tastatur. Gleichzeitig steigen die Anforderungen an Sicherheit und Nachvollziehbarkeit: Wer durfte wann welche Credentials sehen? Wie schnell lassen sich Rechte beim Offboarding entziehen? Wie rotiert man Schlüssel, ohne Clients neu auszurollen? Besonders heikel sind gemeinsam genutzte Geräte wie Kiosk-Displays: Hier gibt es keinen „persönlichen“ Login zum Drittservice, trotzdem müssen Inhalte aus verschiedenen Quellen sicher angezeigt werden. Kurz: Es fehlt ein zentraler, unternehmensweiter Mechanismus, der Identität (Microsoft-Konten) mit Berechtigung (Gruppen/Rollen) verknüpft und einfache Fremd-Credentials sicher, bedarfsgerecht und auditierbar an die richtige Stelle bringt – ohne dass Secrets jemals im Klartext im Client auftauchen.

Projekt für Ravensburger · Schnitzer Group

Das Ziel ist, die bestehende Microsoft-Identität zum Dreh- und Angelpunkt für alle Zugriffe zu machen – auch jenseits der Microsoft-Welt. Mitarbeitende sollen sich nur noch mit ihrem Firmenkonto anmelden und automatisch genau die externen Zugänge erhalten, die sie für ihre Rolle benötigen. Die Lösung liefert einfache Dritt-Credentials ausschließlich on demand nach erfolgreicher Authentifizierung und Autorisierung, speichert sie nicht im Client und erlaubt eine feingranulare Steuerung über Gruppen und Rollen. Für Administratoren entsteht damit ein zentraler Ort, an dem Berechtigungen definiert, Zugriffe nachvollzogen und Credentials ausgetauscht werden können – ohne Rollout-Orgie und ohne Risiko von „Credential Sprawl“. Entwicklerinnen und Entwickler integrieren das Ganze mit minimalem Aufwand: MSAL-Login, gesicherter Aufruf der Azure Function, fertig. Sicherheitsseitig zielen wir auf das Prinzip der minimalen Rechtevergabe, klare Trennung von Identität und Secret, durchgängige Transportverschlüsselung und eine einfache Erweiterbarkeit: Neue Dritt-APIs lassen sich in Minuten anbinden, Schlüssel lassen sich zentral rotieren, und Offboarding wird zum Schließen einer Gruppenmitgliedschaft statt zur Suche nach verstreuten Passwörtern. So entsteht ein nahtloses SSO-Erlebnis für die Nutzer, ein belastbares Governance-Modell für die IT – und deutlich weniger operative Komplexität für alle Beteiligten.

SSO für Dritt-APIs · Zero-Secret-Client

SSO für Dritt-APIs – ohne Secrets im Client

Ergebnis

Weniger Reibung für Nutzer, weniger Risiko für IT: keine wiederkehrenden Logins in Dritt-Systemen, keine Passwörter in Apps/Configs, sauber nachvollziehbar.

Besonderheit

Gruppen-/Rollensteuerung via Entra ID, zentrale Rotation/Offboarding, Credentials nur bei berechtigtem Zugriff – ideal auch für Kiosk- und Shared-Device-Szenarien.

Tech-Stack

Azure Function (gesicherte API) · Microsoft Entra ID (Login & Gruppenprüfung) · MSAL im Client · SQLite als zentraler Credential Store · Logging/Telemetry für Nachvollziehbarkeit.

Lösung besprechen ↗

–100 % Secrets im Client +1 Zentraler Ort für Rechte

Ausgangssituation

Wenn Client-Server-Modelle zu Passwort-Wildwuchs führen

Historisch gewachsene IT-Landschaften kombinieren Microsoft 365 mit Dritttools und Legacy-Systemen. Wiederkehrende Logins, einfache Auth-Verfahren (API-Key/Basic Auth) und Workarounds erzeugen Reibung – und echte Sicherheitsrisiken.

Secrets im Client Zugangsdaten landen in Clientcode, Konfigurationsdateien oder Git-Repos – schwer kontrollierbar und riskant.
Unsichere Workarounds Passwörter auf Post-its oder „geteilte“ Accounts entstehen, weil es keinen sauberen Mechanismus für Dritt-Services gibt.
Kiosk-/Shared Devices Kein persönlicher Login möglich, aber Inhalte aus Drittquellen müssen trotzdem sicher angezeigt werden.

Fehlende Governance Wer durfte wann welche Credentials sehen? Ohne zentrale Spur werden Audits und Nachweise schwierig.
Offboarding & Rotation sind teuer Rechte entziehen und Schlüssel rotieren wird zur Suche nach verteilten Passwörtern – inkl. Client-Rollouts.
Produktivitätsverlust Ständige Kontextwechsel und Logins kosten Zeit – und führen zu Fehlern im Betrieb.

Zielbild

Microsoft-Identität als Dreh- und Angelpunkt – auch für Fremd-Services

Mitarbeitende melden sich einmal mit dem Firmenkonto an. Alles Weitere (Berechtigung, Zugriff, Rotation, Offboarding) wird zentral gesteuert – ohne Secrets im Client und mit klarer Audit-Spur.

SSO-Erlebnis

Ein Login mit Firmenkonto genügt – keine separaten Passwörter für Drittanbieter.

Zero-Secret-Client

Keine Secrets in Code, Config oder Geräten – Credentials nur temporär und bedarfsgerecht.

Governance & Audit

Nachvollziehbarkeit: wer, wann, welche Credentials angefordert hat.

Schnell erweiterbar

Neue Dritt-APIs in Minuten anbinden; Schlüssel zentral rotieren.

Lösungsbausteine

Azure Function als Broker

Prüft Microsoft-Token, ermittelt Gruppen/Rollen und entscheidet, ob ein Zugriff erlaubt ist.

Zentraler Credential Store

Zugänge liegen zentral (z. B. SQLite) und werden nur „on demand“ an berechtigte Clients ausgeliefert.

Rollen-/Gruppensteuerung

Berechtigungen über Entra ID Gruppen: Offboarding ist Gruppenentzug, nicht Passwortsuche.

Rotation ohne Rollouts

Keys/Secrets einmal zentral aktualisieren – angebundene Apps ziehen beim nächsten Abruf automatisch.

Aus Sicht der Anwender

SSO, aber für alles – ohne dass irgendwer Secrets anfassen muss

Operative Rolle

Mitarbeitende / Fachbereiche

Ich melde mich mit meinem Firmenkonto an und arbeite los. Dritt-Services funktionieren im Hintergrund – ohne zusätzliche Passwörter und ohne Reibung.

Governance Rolle

IT / Security

Berechtigungen sind zentral. Offboarding und Rotation sind sauber geregelt – und wir sehen nachvollziehbar, wer wann Zugriff angefragt hat.

Delivery Rolle

Entwicklung

MSAL-Login, Token an die Azure Function, fertig. Keine Secrets im Code, keine Sonderlogik für Kiosk-Geräte – Integration bleibt schlank.

User Story

Ein typisches Szenario: Ein Kiosk-Display oder ein Shared Device soll mehrere Dritt-Services anzeigen – etwa Dashboards aus einem SaaS-Tool, Inhalte aus einer Legacy-API und Statusdaten aus einem Spezialsystem. Früher endete das in Workarounds: ein „Shared Account“, Credentials in Configs oder im Clientcode, unklare Zuständigkeiten beim Offboarding – und Rotation nur mit Rollout-Aufwand. Mit dem SKOUZ Credential Service läuft es anders: Der Client authentifiziert über Entra ID (MSAL). Eine Azure Function prüft Token + Gruppen/Rollen und liefert nur bei Berechtigung die benötigten Fremd-Credentials „on demand“ aus dem zentralen Store. Für Admins entsteht ein auditierbarer Nachweis (wer/wann/was) – und Rotation oder Entzug passiert zentral, ohne Geräte neu auszurollen.

Ideal für Unternehmen, die…

SSO-Logik auf Mixed-Stacks ausrollen wollen

Microsoft 365/Entra ID nutzen und zusätzlich externe/Legacy-APIs anbinden
Passwörter aus Anwendungen verbannen und Berechtigungen zentral steuern wollen
Shared Devices/Kiosk-Szenarien sicher betreiben müssen
Rotation & Offboarding ohne Rollout-Orgie etablieren möchten

Identity & Access Security & Compliance Mixed Stacks

Technologie & Projekt-Fakten

Kunden: Ravensburger · Schnitzer Group
Pattern: Identity → Broker → Third-Party Credentials (on demand)
Auth: Entra ID + MSAL (Token) · Gruppen-/Rollenprüfung
Runtime: Azure Functions (gesicherte API)
Credential Store: SQLite (zentral) – keine Secrets im Client

Lösungsbeschreibung

Identity-first Credential Broker – ohne Secrets im Client

Der Credential Service liefert Zugänge für Dritt-Systeme zentral, kontrolliert und nachvollziehbar aus: Entra ID Login, Policy-Checks, kurzlebige Ausgabe und Audit-Trail – damit Teams schneller integrieren, ohne Sicherheitskompromisse.

Entra Login → Request → Policy → Token/Secret → Audit

1 / 4

Keine Passwörter mehr verteilen

Clients bekommen Credentials nur bei Bedarf – nicht als dauerhaftes Secret in Appsettings, Git, Devices oder Tickets.

2 / 4

Zugriff über Identität & Rolle

Entra ID (MSAL) ist der Einstieg: Rollen/Groups entscheiden, wer welche Zielsysteme und Aktionen nutzen darf.

3 / 4

Governance, die wirklich greift

Policy-Check: Claims/Rollen + Service-Regeln (Scope, Mandant, Umgebung, Rate-Limits)
Kurzlebige Ausgabe: Tokens/Secrets zeitlich begrenzt, entziehbar, rotierbar – ohne Client-Rollout
Audit-Trail: jede Ausgabe nachvollziehbar (wer/wann/was/wofür) – compliance-ready
Monitoring: Alarme bei Auffälligkeiten (Frequenz, Rollenfehler, Uhrzeiten, ungewöhnliche Ziele)

4 / 4

Schneller onboarden, stabil betreiben

Neue Zielsysteme werden als „Service“ standardisiert angebunden. Einheitliche API, gleiches Muster – weniger Sonderfälle im Betrieb.

Funktion → Vorteil / Nutzen

Entra ID Login (MSAL) statt Shared Accounts

Zugriff ist personalisiert, nachvollziehbar und sofort entziehbar (Offboarding/Role Change)

Credentials „on demand“ statt in Clients/Config/Git

Reduziert Leaks und Shadow-Secrets – weniger Risiko, weniger Aufräumaufwand

Policy-Check pro Service/Umgebung

Klare Regeln verhindern Fehlzugriffe (z. B. Prod vs. Test, Mandanten, Scopes)

Zentrale Rotation & Entzug

Passwortwechsel ohne Client-Updates – schneller reagieren, weniger Downtime

Kurzlebige Tokens / zeitlich begrenzte Ausgabe

Begrenzt Schadensradius – Zugriff endet automatisch, auch bei Leak

Audit-Log je Ausgabe (wer/wann/wofür)

Belastbare Historie für Audits, Security Reviews und Incident-Analyse

Monitoring & Alerts

Erkennt Missbrauch/Fehlkonfiguration früh – bessere Betriebssicherheit

Standardisierte API pro Zielsystem

Teams integrieren schneller – gleiches Muster, weniger Sonderlogik

Support für Shared/Kiosk Devices

Sicherer Zugriff ohne „Shared Password“ – trotzdem praktikabel im Alltag

Trennung Dev/Test/Prod über Regeln

Keine Vermischung von Umgebungen – reduziert Produktionsrisiken

Next Step

Wollen wir Dritt-Services sicher an Entra ID andocken?

In einem kurzen Austausch klären wir, welche Dritt-APIs, Legacy-Tools oder Kiosk-Szenarien bei Ihnen relevant sind – und wie wir eine zentrale, auditierbare Credential-Vergabe ohne Secrets im Client aufsetzen.

Jetzt unverbindlich anfragen ↗

Antwort garantiert innerhalb von 24 Stunden.