Zero-Touch OAuth für MCP

 (blog.modelcontextprotocol.io)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Erweiterung Enterprise-Managed Authorization (EMA) wurde stabilisiert, sodass Unternehmen Berechtigungen für MCP-Server zentral verwalten können und Nutzer sich einmal anmelden, um auf freigegebene Server zuzugreifen
  • Der bisherige Ansatz beruhte auf individuellen OAuth-Freigaben pro Nutzer und pro Server, was Onboarding, die Durchsetzung von Sicherheitsrichtlinien, Audit-Trails und die Trennung von Arbeits- und Privatkonten erschwerte
  • EMA legt den IdP der Organisation als Instanz für Zugriffsentscheidungen fest; definiert ein Administrator die Richtlinien einmal, erben Nutzer die benötigten MCP-Verbindungen über ihr bestehendes Organisationskonto
  • Während SSO ausgestellte ID-JAGs werden beim Authorization-Server des MCP-Servers gegen Access Tokens ausgetauscht, sodass Nutzer nicht zu serverbezogenen Einwilligungsbildschirmen umgeleitet werden
  • Zur ersten Unterstützungsrunde gehören Okta, Anthropic, Visual Studio Code sowie Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase; auch Slack fügt Unterstützung hinzu

Stabilisierung von EMA und Zielrichtung für den Unternehmenseinsatz

  • Die Erweiterung Enterprise-Managed Authorization (EMA) hat den Status stable erreicht
  • Beim Verwalten von MCP-Serververbindungen in Unternehmensumgebungen galten wiederholte Freigaben und Consent-Prompts als große Hürde; EMA ist eine Erweiterung, die dieses Problem verringern soll
  • Organisationen können den Zugriff auf MCP-Server zentral über ihren vertrauenswürdigen Identity Provider (IdP) steuern
  • Endnutzer melden sich mit ihrem bestehenden Organisationskonto an und verbinden sich dann mit freigegebenen MCP-Servern; serverbezogene OAuth-Einwilligungen oder einmalige Einrichtungsschritte entfallen weitgehend

Grenzen des nutzerbezogenen Authentifizierungsmodells

  • Das Standard-Berechtigungsmodell von MCP wurde auf user-scoped Zugriffe und traditionelle interaktive Authentifizierungsabläufe ausgelegt
  • Für Consumer-Szenarien, in denen Einzelpersonen selbst festlegen, worauf ihre Daten zugreifen dürfen, kann das passend sein, für Unternehmensrollouts skaliert es jedoch schlecht
  • In Unternehmensumgebungen treten besonders drei Probleme auf
    • Mitarbeitende müssen jeden Server einzeln freigeben, wodurch beim Onboarding manuelle Verbindungen pro Dienst erforderlich werden
    • Sicherheitsteams sind auf von einzelnen Nutzern freigegebene Zugriffe angewiesen, ohne zentrale Kontrolle oder durchgängige Audit-Trails
    • Unternehmenskonten lassen sich nur schwer erzwingen, sodass Nutzer private Konten mit Arbeitstools verbinden können
  • Diese Reibung verlangsamt die Einführung von MCP und erhöht die Wahrscheinlichkeit fragiler Workarounds
  • Ohne einen allgemeinen Standard zur Bewahrung gemeinsam genutzter Authentifizierungszustände baut jeder Implementierer eigene Lösungen; selbst wenn Daten und Tools vorhanden sind, könnten sie wegen der Kosten nutzerbezogener Berechtigungen meist deaktiviert bleiben

Einmal freigeben und überall erben

  • Enterprise-Managed Authorization macht den IdP der Organisation zur Instanz für Zugriffsentscheidungen auf MCP-Server
  • Administratoren definieren Richtlinien einmal, und Nutzer authentifizieren sich beim MCP-Host mit ihrer bestehenden Organisations-ID
  • Der IdP kann den Zugriff abhängig von Gruppenmitgliedschaften, Rollen und Regeln für bedingten Zugriff erlauben oder verweigern
  • Der interne Ablauf sieht wie folgt aus
    • Der Client erhält während SSO vom IdP ein Identity Assertion JWT Authorization Grant (ID-JAG)
    • Der Client sendet es an den Authorization-Server des MCP-Servers und tauscht es gegen ein Access Token aus
    • Nutzer müssen keinen serverbezogenen Einwilligungsbildschirm durchlaufen
  • Diese Struktur hat drei Effekte
    • Aktiviert ein Administrator einen Server für die Organisation, erhalten Nutzer innerhalb bestehender Gruppen- und Rollenbereiche automatisch Zugriff
    • Zugriffsentscheidungen werden in der Admin-Konsole des IdP protokolliert und liefern so einen einheitlich auditierbaren Verlauf für alle Konnektoren
    • Durch den Wegfall interaktiver Schritte zur Kontoauswahl lassen sich Verwechslungen bei Datenflüssen zwischen privaten und geschäftlichen Konten leichter reduzieren
  • Ziel im Unternehmenseinsatz von MCP ist ein Zustand, in dem sich der Client nach dem Login des Nutzers ohne zusätzliche Schritte mit freigegebenen Tools und Daten verbindet

Produkte mit früher Unterstützung und das Ökosystem

  • An diesem Release beteiligen sich drei Gruppen an der Implementierung: Identity Provider, Clients und Server

  • Identity Provider

    • Okta ist der erste unterstützte Identity Provider
    • Organisationen, die Okta nutzen, können über Okta’s Cross App Access (XAA) den MCP-Zugriff für unterstützte Clients und Server bereitstellen

  • Clients

    • Anthropic implementiert EMA in Claudes gemeinsam genutzter MCP-Schicht
    • Administratoren können MCP-Server für Nutzer über Claude, Claude Code und Cowork hinweg freigeben
    • Auch Visual Studio Code ergänzt Unterstützung für EMA in der IDE

  • Server

    • Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase unterstützen EMA
    • Slack und weitere Server fügen ebenfalls Unterstützung hinzu
    • Aaron Parecki von Okta sagt, dass durch die Einbettung des Cross App Access-Protokolls in die EMA-Erweiterung von MCP Identität zu einer zentralen Governance-Ebene wird, Sicherheitsteams Compliance-Kontrollen erhalten und Nutzer eine reibungslose Erfahrung bekommen
    • Devdatta Akhawe von Figma sagt, dass XAA mit wachsender MCP-Einführung die sichere Skalierung von MCP-Rollouts in Unternehmen erleichtert
    • Tom Moor von Linear verweist auf eine Erfahrung, bei der nach einer einzigen Anmeldung alle MCP-Konnektoren automatisch eingerichtet werden

Dokumentation und Beteiligungskanäle

  • Clients, Server und Identity-Plattformen können die Spezifikation der Erweiterung prüfen und Unterstützung für den neuen Standard zu ihren Produkten hinzufügen
  • Die Seite zu Enterprise-Managed Authorization dokumentiert die Ablaufanforderungen für Clients, Server und Authorization-Server
  • Im ext-auth-Repository und in der Draft-Spezifikation lassen sich die neuesten Änderungen und Materialien zu EMA verfolgen
  • Für Diskussionen zur Erweiterung, Kompatibilitätsberichte und iterative Verbesserungen wird die EMA Interest Group genutzt
  • EMA ist eine Community-Arbeit rund um MCP, zu der die Autorinnen und Autoren von SEP-990, die Maintainer des ext-auth-Repositorys sowie Identity- und MCP-Provider beigetragen haben, die frühe Implementierungen getestet und die Spezifikation vorangebracht haben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Bevor das wieder in die übliche Debatte „MCP ist tot und Skills sind die Zukunft“ abdriftet: Der tatsächliche Mehrwert von MCP gegenüber Skills/CLI besteht darin, dass es den Authentifizierungs-Flow außerhalb des Kontextfensters des Agenten verlagert, in manchen Fällen sogar außerhalb des Harness
    Das ist aus Sicherheitssicht selbstverständlich wichtig und sorgt auch für eine deutlich einfachere User Experience, wenn normale Nutzer oder große Unternehmen AI-Tools einführen
    Ich verstehe die Beschwerden über aufgeblähte Kontexte oder doppelte Tool-Aufrufe, aber diese Art, Authentifizierung zu handhaben, hat eindeutig ihren Wert
    Ein ideales MCP könnte schon allein als Authentifizierungs-Gateway vor einer API ausreichend Nutzen bringen

    • Diese Erweiterung zeigt im Vergleich zu Skills auch andere Vorteile von MCP gut auf: zentrale Kontrolle, Benutzerfreundlichkeit aus Mitarbeitersicht, Audit-/Compliance-Aspekte und das Deployment-Modell
      Der derzeit beste Weg, Skills auszurollen, scheint etwa zu sein: „Kopiere diese Datei und lege sie hier ab“, „Checke dieses Repository aus und füge einen symbolischen Link hinzu“ oder „Installiere es per Slash-Command“
      Das ist zwar einfach, aber nicht so leicht wie diese Erweiterungsmethode, mit der sich neue MCP-Server an Mitarbeitende verteilen lassen
    • MCP ermöglicht außerdem eine hervorragende Audit-Trail-Führung
      Zum Beispiel könnte man 6 Linear-Konten von 6 Kundenunternehmen authentifizieren und dann auf deterministische und auditierbare Weise auswählen, welches Konto verwendet werden soll — eine Form von Aufgabentrennung
    • Die eigentliche Lehre ist, dass MCP vs. Skills keine Dichotomie ist
      Es sind einfach unterschiedliche Werkzeuge, und je nach Anforderung kann das eine besser passen oder eben nicht
      Das ist ungefähr so, als würde man fragen, ob ein Messer oder eine Säge besser ist
    • Darüber hinaus erlaubt MCP die Anbindung externer Plattformen ohne Runtime-Umgebung
      Immer wenn dieses Thema aufkommt, tun Engineers so, als wäre Claude Code die einzige App für AI-Agenten, aber es gibt in vielen Branchen außerhalb des Codings zahlreiche Anwendungsfälle
      Das Harness kann in einem isolierten und eingeschränkten Container in der Cloud laufen statt auf einer lokalen Maschine, und die Ausführung beliebigen Codes kann vollständig untersagt sein
      Wenn Kunden ihre bestehenden Tools trotzdem an einen Agenten anbinden wollen, passt MCP genau, weil es Konnektoren mit integrierter Authentifizierung bereitstellt; Skills gehören nicht in diesen Bereich
    • Ich baue eine Plattform für Restaurantbewertungen mit Freunden, und nach einigem Hin und Her scheint MCP der richtige Weg zu sein
      Normale Nutzer suchen nicht das Claude-Verzeichnis, um dort Skill-Dateien hineinzukopieren
      „Connections“ ist leicht zu verstehen, und es ist einfacher, ein MCP einzufügen oder es in einem Marktplatz zu finden
      Ob es tatsächlich nützlich ist, dem Agenten Zugriff auf Orte und Bewertungen zu geben, ist noch offen

  • Großen Glückwunsch an die Leute bei Okta, Anthropic, Microsoft, Figma, Linear usw., die daran gearbeitet haben
    Auch für MCP-Skeptiker ist hier etwas Brauchbares dabei
    Das funktioniert mit einem neuen Token-Format namens ID-JAG, beschrieben unter https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
    Das ist überhaupt nicht MCP-spezifisch; ID-JAG kann überall dort eingesetzt werden, wo Daten sicher zwischen Anwendungen ausgetauscht werden müssen, die denselben SSO-Anbieter verwenden

    • Angesichts dessen, dass solche Unternehmen Software und Lebensqualität verschlechtert haben, wirkt „Glückwunsch“ eher zynisch

  • Ich versuche gerade, Microsoft-Entra-ID-Authentifizierung an einen MCP-Server anzubinden, den ich implementiere, und ehrlich gesagt fühle ich mich dabei wie ein Idiot
    Über den Header WWW-Authenticate kann man dem Client die URL der Ressourcen-Metadaten mitteilen; darüber lassen sich auch Microsoft Entra als Autorisierungsserver und der Bereich der App-Registrierung angeben
    Aber client_id lässt sich nicht festlegen; stattdessen heißt es, jeder Client, also jeder Agent, erstellt sie selbst
    Um den Login über die Entra-URL .../authorize zu starten, braucht man jedoch eine bekannte client_id, die zu einer App-Registrierung in Entra passt, und ein vom Client frei erfundener Wert wird kaum zu Entra passen
    Theoretisch könnte man dynamische Client-Registrierung unterstützen, aber Microsoft Entra unterstützt das natürlich nicht
    Am Ende scheint nur übrig zu bleiben, vor Microsoft Entra ein eigenes Shim für dynamische Client-Registrierung zu bauen, das allen dieselbe statische client_id zurückgibt
    Ich habe das Gefühl, etwas Offensichtliches zu übersehen, denn es kann doch nicht sein, dass dieses Protokoll in echten Enterprise-Umgebungen nur mit Workarounds funktioniert

    • Es sieht nicht so aus, als würdest du etwas Offensichtliches übersehen
      Entra ID unterstützt dynamische Client-Registrierung nicht, und der Zustand dieses Ökosystems ist noch nicht besonders gut
      Üblicherweise wird MCP OAuth mit vorab registrierten klassischen Clients abgewickelt, aber viele MCP-Clients gehen in der Praxis davon aus, dass dynamische Client-Registrierung verfügbar ist, und bieten keine Option zum Setzen einer client_id
      Einige Clients unterstützen das allerdings, und in eigener Sache: unser Tool Erato unterstützt es ebenfalls: https://erato.chat/docs
      Übliche Lösungen für Enterprise-Deployments zentralisieren den MCP-Zugriff meist ohnehin über eine Web-UI und unterstützen das deshalb
      Eine weitere Alternative ist ein MCP-Gateway; zwischen Gateway und Service kann man vorab registriertes OAuth verwenden und zwischen Gateway und Client dynamische Client-Registrierung zulassen
    • Wir hatten wegen client_id dasselbe Problem und wollten dynamische Client-Registrierung aus Sicherheitsgründen nicht aktivieren
      Letztlich haben wir die App den OAuth-Flow proxyen lassen und dabei eine hartcodierte client_id injiziert
      Gegenüber dem MCP-Client tun wir so, als würde dynamische Client-Registrierung unterstützt, intern verwenden wir aber wie gewohnt eine separate client_id für MCP
      Ein Beispiel gibt es hier: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • Ich habe das erst gestern implementiert; der Kern ist, dass diese Bibliothek den MCP-Server ausführt: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      Danach habe ich eine Authentifizierungs-Broker-Anwendung gebaut, die die Client-Registrierung per OpenID verarbeitet und JWTs erstellt
      Dadurch können wir nun anhand der Abteilung eines Mitarbeiters oder anderer Kriterien entscheiden, ob ein Tool genutzt werden darf und mit welchen Berechtigungen
      Letztlich ist dynamische Client-Registrierung also erforderlich
    • Kürzlich hat FusionAuth dokumentiert, wie man vorab registrierte Clients verwendet: https://fusionauth.io/docs/extend/examples/controlling-acces...
      CIMD, der neuere und bessere Bruder von DCR, wird ebenfalls geprüft und aktiv diskutiert, ist aber noch nicht verfügbar: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      Eine Alternative zu dem vorgeschlagenen Proxy wäre, für jeden MCP-Client etwa über ein Developer-Portal eine neue Entra-client_id mit aktiviertem PKCE zu erzeugen und den Nutzer diesen Wert im Client konfigurieren zu lassen
      Den CLI-Befehl dafür habe ich hier gefunden, und vermutlich gibt es auch eine API: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      Die Konfiguration für Claude Code steht unter https://code.claude.com/docs/en/mcp, die für ChatGPT unter https://developers.openai.com/api/docs/guides/developer-mode
      Die vorab registrierte Client-Registrierung ist für Entwickler vielleicht nicht optimal, aber akzeptabel, und wird in der Spezifikation auch als erstklassiger Ansatz behandelt: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      Wenn die Hauptnutzer interne Mitarbeitende sind und sie den Einrichtungsanweisungen für den Zugriff auf den MCP-Server folgen können, funktioniert dieser Ansatz ebenfalls
      Wenn das Ziel jedoch eine breite öffentliche Integration für Nicht-Entwickler ist, ist das eindeutig nicht akzeptabel, und genau darin liegt eine der großen Stärken und Chancen von MCP

  • Ich bin eine der Personen, die das zusammen mit Okta und mehreren MCP-Partnern bei Anthropic gebaut haben.
    Ich freue mich sehr, dass diese Form in Claude Gestalt annimmt, und da EMA inzwischen eine stabile Erweiterung in der MCP-Spezifikation ist, möchten wir die Einführung auch auf andere ID-Provider und Clients ausweiten.
    Wenn ihr Feedback habt, hinterlasst es gern hier; wir hören immer gern von echten Nutzungserfahrungen und wie wir es verbessern können.

    • Lange nicht gesehen.
      Ich habe MCP eine Zeit lang nicht verfolgt, aber das scheint ziemlich gut dazu zu passen, MCP in Organisationen sicherer zu machen und die Schwächen der dynamischen Client-Registrierung zu beheben.
      Da Clients und freigegebene Redirect-URIs nun direkt vom ID-Provider und der Organisation eingerichtet werden können, lassen sich DCR-basierte Angriffe wie Confused-Deputy-Angriffe oder Phishing deutlich umfassender abmildern.
      Ein weiterer großer Vorteil ist, dass auch weniger Autorisierungslogik auf dem MCP-Server implementiert werden muss, wenn der ID-Provider oder die Organisation DCR bisher nicht unterstützt hat.
      Der Nachteil scheint zu sein, dass für Consumer-Nutzung weiterhin DCR nötig ist.
      Das ließe sich vielleicht lösen, wenn Consumer-OAuth-Provider wie GitHub, GitLab und Google statische MCP-Client-/Server-Registrierung unterstützen, Clients eine statische client_id einbetten und Nutzer sich bei diesem ID-Provider anmelden, um die Verbindung selbst zu verwalten.
      Insgesamt wirkt XAA/EMA in puncto Sicherheit und Nutzbarkeit DCR deutlich überlegen.
      Auch die problematischen Punkte scheinen wesentlich leichter lösbar zu sein und geringere Sicherheitsauswirkungen zu haben als bei DCR, weil Angreifer keinen eigenen Client registrieren können und MCP-Server-Entwickler in weniger Fallen tappen.
    • Für allgemeine „Apps“ ist das hervorragend, aber wir brauchen dringend eine Möglichkeit, wie Nutzer agentisch mit deutlich weniger Reibung interagieren können, ohne MCP einzurichten.
      So etwas wie eine temporäre Sitzung oder ein Out-of-Band-Token-Store wäre hilfreich.
      Der Anwendungsfall ist, dass Käufer und Verkäufer im Vertriebsprozess viele Informationen austauschen und analysieren müssen, und diese Analyse wird zunehmend agentisch.
      Das Problem bei MCP ist, dass die Reibung beim initialen Setup viel größer ist, als wenn sich Nutzer einfach selbst anmelden und die benötigten Informationen abrufen.
      MCP ist gut für regelmäßige und häufige Interaktionen, hat aber viele Probleme bei schnellen Einmalsitzungen.
      Wenn man in Claude sagt: „Hol Dokumente aus X, Y und Z“, dann sollte Claude auf die jeweilige Website zugreifen können, und die Seite sollte grundlegende Nutzungsinformationen sowie einen Login-Link zurückgeben, den der Nutzer im Browser öffnen kann.
      Es wäre gut, wenn der Nutzer sich im Browser authentifiziert, der Callback dann ein eindeutiges, kurzlebiges Einmal-Token zurückgibt und dieses anschließend bei Anfragen an die Website eingetauscht wird.
      So könnte man Nutzer schnell authentifizieren und zugleich den Sitzungszustand während der Arbeit aufrechterhalten.
    • Ich frage mich, ob es Austausch mit dem Microsoft-Entra-, also dem Azure-AD-Team gibt.
      Würde mich interessieren, ob man das bald erwarten kann oder ob es noch ziemlich lange dauern wird.
    • Glückwunsch zum Release.
      Der primäre Anwendungsfall scheinen Firmenmitarbeiter zu sein, aber ich frage mich, ob es auch einen ähnlichen Nutzen für nicht zentralisierte Nutzer gibt, etwa Kunden oder Premium-Free-User.
      Mir fällt da nicht viel ein, deshalb wollte ich wissen, ob ich etwas übersehe, und ich glaube, eine relevante Antwort dazu habe ich hier gesehen: https://news.ycombinator.com/item?id=48594381
    • Ich möchte nur bestätigen, dass das noch nicht tatsächlich nutzbar ist und sich noch im SEP-Stadium befindet.

  • Das ist wirklich großartig.
    Ich hatte in den letzten Monaten das Glück, zusammen mit Leuten aus dem MCP-Umfeld an einigen SEPs und einem experimentellen SDK für Go zu arbeiten.
    Früher war ich ein Skeptiker, der sagte: „Das ist doch einfach nur eine API“ oder „Da wird wieder eine Abstraktion obendrauf gesetzt“.
    Was Leute übersehen, ist, dass das „P“ in MCP irreführend ist.
    Wenn man eine traditionelle App baut, muss man Formulare, UI, Request-/Response-Verarbeitung, bidirektionale Kanäle, langlaufende Aufgaben, Authentifizierung usw. bauen.
    Mit MCP werden 80 % dieser gemeinsamen Schicht übernommen, daher ist MCP zwar ein Protokoll, aber eigentlich eher ein App-Framework.
    Integrierte Authentifizierung ist ein enormer Fortschritt, und ich freue mich auf noch mehr coole Dinge.

  • Es ist ziemlich verrückt, meine Arbeit da draußen sichtbar zu sehen.
    Ich war bei Atlassian für die RAS-seitige Implementierung dieses Flows verantwortlich.
    Es wird in diesem Flow sicher iterative Verbesserungen geben, etwa bei CIMD, besserer Tenancy-Unterstützung und mehr.
    Alle bei Anthropic, Okta und Atlassian, die das ausgeliefert haben, waren großartig.

  • Es wäre gut, wenn Web unterstützt würde, damit man einfach langfristige Cookies ausstellen könnte.
    Ich habe die Spezifikation gehackt, damit Cookies per OAuth-Handshake durchgereicht werden können, um das ohne OAuth-Server zu machen.
    Dass so etwas nicht erlaubt sein soll, ist wirklich frustrierend.
    Wenn kein Cookie da ist, öffnet man die Webseite, und wenn das Cookie gesetzt ist, schließt und speichert man sie einfach.
    Ich habe sogar ein 80-seitiges Minibuch über MCP geschrieben, und trotzdem ist es weiterhin endlos frustrierend.

    • Ich bin einer der Lead-Maintainer des MCP-Projekts, und dieser Ansatz skaliert in mehreren Szenarien nicht.
      Es gibt Probleme sowohl bei der Nutzbarkeit als auch bei der Sicherheit, und Cookies wurden für Browser gemacht.
      MCP-Server und -Clients laufen oft in Umgebungen, in denen ein Browser nicht garantiert ist.
    • Das kommt im Grunde fast einer Bitte gleich, Anmeldedaten stehlen zu dürfen.
      Langfristige Zugangsdaten sind eine große Verantwortungslast.

  • Ich habe es mehrmals gelesen, und es ist definitiv nützlich.
    Auditierung und Zugriffskontrolle an einer Stelle beim ID-Provider zu zentralisieren und den ID-Provider bei Bedarf wie ein Proxy-API-Gateway für den Token-Austausch agieren zu lassen, ist ein Ansatz, den auch andere Akteure in diesem Bereich übernommen haben.
    Persönlich ist mir etwas unwohl bei dem Gedanken, dass der ID-Provider meine Berechtigungen an Clients delegiert, ohne dass ich mir dessen bewusst bin.
    Vielleicht liegt das daran, dass ich zu sehr an Flows gewöhnt bin, in denen der Nutzer im Browser präsent ist; es fühlt sich an, als entwickle sich das immer stärker zu zentralisiertem Zugriff für Maschinen.
    In Enterprise-Umgebungen mag das akzeptabel sein, weil die Identität eher dem Unternehmen als der einzelnen Person gehört.
    Eine Integration in den Customer-ID-Bereich ist jedoch eine ganz andere Herausforderung, und solches Vertrauen zwischen ID-Provider, Client und Resource Authorization Server aufzubauen, dürfte vermutlich nicht einfach sein.

    • Es gibt keine theoretische Hürde, die diese Integration daran hindern würde, im Consumer-Bereich zu funktionieren.
      Man könnte zum Beispiel Vertrauensbeziehungen schaffen, sodass man, wenn man bei GitHub eingeloggt ist, auch automatisch bei Sentry eingeloggt wird.
      Es gibt noch viel zu tun, aber der derzeit klarste Anwendungsfall ist, wie du sagst, Enterprise.
      Administratoren möchten nicht, dass einzelne Mitarbeiter überall herumklicken und beliebige Zugangsdaten auswählen.

  • Bei C1 war MCP-Authentifizierung sowohl für die interne MCP-Nutzung als auch für das MCP Gateway im Produkt ein großes Ärgernis, daher ist es sehr erfreulich, dass das jetzt kommt
    Heute hat C1 Support dafür veröffentlicht, als EMA-ID-Provider zu fungieren, und gibt kurzlebige, bereichsbeschränkte Tokens aus
    Ich möchte das jetzt mit Linear und den anderen MCPs verbinden, die wir nutzen, um den wiederholten OAuth-Flows zu entkommen
    Claude hat so etwas bei einigen eingebauten Konnektoren, zumindest bei Slack, bereits wie von Zauberhand erledigt, und die Erfahrung ist ziemlich gut
    Zur Offenlegung: Ich bin VPE bei C1, und wir haben den Ansatz für alle, die tiefer einsteigen wollen, dokumentiert: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • Ich verstehe nicht ganz, welchen Vorteil das gegenüber normalem OAuth hat
    Ich glaube, es braucht ein Beispiel zum Vergleich der Autorisierungs-Flows

    • Bei normalem OAuth stimmt der Endnutzer jeder einzelnen Anwendung individuell zu, ob sie seine Daten teilen darf
      Das ergibt Sinn für Consumer-Anwendungsfälle, also wenn der Endnutzer seine Daten selbst besitzt
      In vielen Business-Anwendungsfällen ist jedoch nicht der Endnutzer die Instanz, die Daten teilen und den Zugriff kontrollieren sollte, sondern das Unternehmen
      Wenn ich Mitarbeiter bei Acme bin, sollte ich nicht entscheiden dürfen, ob Acme-Google-Drive-Daten mit Claude oder ChatGPT verbunden werden; das sollte die IT-Abteilung festlegen
      Enterprise-Managed OAuth oder Cross App Access (XAA) bringt dieses von der IT zentral gesteuerte Freigabemodell in das OAuth-Framework, sodass es mit dem bestehenden Ökosystem zusammenarbeitet
      Außerdem hat es große UX-Vorteile, wenn die Verwaltung der Zustimmung zur Datenfreigabe vom Mitarbeiter auf den IT-Administrator verlagert wird
      Mitarbeiter müssen nicht mehrere OAuth-Flows durchlaufen, um Konten zu verbinden, weil der IT-Administrator die Freigabekontrollen bereits eingerichtet hat
      Man kann sich das so vorstellen, dass am ersten Arbeitstag Slack bereits mit Zoom, Drive, Calendar usw. verbunden ist
    • Der Vorteil ist, dass Nutzer nicht steuern oder ihnen zustimmen müssen, welche Apps untereinander ihre Informationen teilen dürfen
      Denn die Entscheidung über die Zugriffsdelegation wird auf der Richtlinienebene des ID-Providers getroffen
      Nutzer erfahren möglicherweise nie, welche Apps oder Services berechtigt wurden, ihre Informationen zu teilen
      Moment mal, ist das wirklich ein Vorteil? ;-)