Claude koppelt connectors nu automatisch: IdP-variant GA, Claude als trusted issuer in bèta

Anthropic heeft op 3 november 2026 een manier aangekondigd om connectors in Claude op organisatieniveau te autoriseren in plaats van per gebruiker. Het bijbehorende supportartikel, 'Auto-connect your organization's apps to Claude', vat de bedoeling zo samen:

"you authorize a connector once for your entire organization, and your team inherits access automatically on first login."

Voor beheerders is vooral de combinatie van die twee varianten relevant. De IdP-route leunt op bestaande SSO en IdP-groepen, de Claude-issued route laat Claude zelf een signaal aan de connector geven zonder identity provider. Welke variant je kiest, bepaalt hoe entitlements, scopes en offboarding in de praktijk lopen. Hieronder staan de werking, de configuratiestappen, de beperkingen en de technische laag eronder, met per statusclaim steeds de variant erbij.

Wat er verandert

De wijziging is in de kern een verschuiving van per-gebruiker consent naar organisatiebrede autorisatie. Waar een medewerker voorheen zelf een connector moest koppelen en daarbij een consent-scherm langsging, kan een organisatie de connector eenmalig autoriseren en laten meelopen met de identiteit die al bestaat. Anthropic beschrijft dat als: de organisatie autoriseert een connector één keer, het team erft de toegang automatisch bij de eerste login.

Dat betekent niet dat persoonlijke connectors verdwijnen. Persoonlijke connectors blijven mogelijk bovenop de beheerde route, staat in de supportdocumentatie. Browser sign-in en managed authorization kunnen tegelijk aan staan; Claude probeert eerst managed authorization en valt terug op individuele sign-in als dat niet lukt. Die volgorde is praktisch: je houdt de beheerde route als default zonder gebruikers volledig buitensluiten.

Het is los te zien van andere aankondigingen uit dezelfde week. Anthropic's message threads van 2 november 2026 zijn een ander product: server-side conversatiepersistentie in de Messages API, geen connector-authenticatie. Wie de zakelijke kant van Anthropic volgt, vindt die in de analyse van Anthropic's S-1/A; dat staat los van de connectorfunctie.

Connectors, apps of plugins: de naamgeving

De naamgeving loopt uiteen, en dat is voor documentatie en zoekwerk handig om te weten. Het supportartikel gebruikt in de body consequent de term 'connectors', terwijl de titel van datzelfde artikel over 'apps' spreekt. Anthropic's berichten op X over dezelfde functie — van @ClaudeDevs op 3 november 2026 en van Boris Cherny (@bcherny) — noemen ze 'plugins'.

Voor je eigen runbook en voor communicatie naar gebruikers is het verstandig één term te kiezen en de andere te vermelden. In dit artikel is dat 'connectors', met de aantekening dat dezelfde functionaliteit op X als 'plugins' langskomt. Wie in de beheeromgeving zoekt, vindt de instellingen onder connectors, niet onder plugins.

Twee identiteitsbronnen

Elke connector gebruikt op een gegeven moment één identiteitsbron. De eerste is IdP-managed: die "relies on single sign-on (SSO) being enabled on Claude and the connector. With that in place, the IdP signs the user into the connector." De identiteit wordt geërfd uit bestaande identity-provider-groepen en -rollen. De tweede is Claude-issued (bèta): Claude geeft aan de connector door welke gebruiker bij Claude is ingelogd, onder een issuer-URL die uniek is voor jouw organisatie. Daarvoor is geen identity provider of SSO nodig; gebruikers worden bij de connector gematcht op e-mailadres.

Die tweedeling is geen detail. Bij IdP-managed blijven toegangsbeslissingen en scoping bij het beleid van je identity provider en bij de permissies van de gekoppelde dienst, niet bij Anthropic. Bij Claude-issued doet Claude een uitspraak over lidmaatschap, en niet meer dan dat. Welke bron je per connector kiest, bepaalt dus waar je toegangsbeleid woont.

IdP-managed: algemeen beschikbaar

IdP-managed auth is de variant die algemeen beschikbaar is. De voorwaarde is dat SSO aanstaat op Claude én op de connector; als dat geregeld is, tekent de IdP de gebruiker in bij de connector. Omdat de identiteit uit bestaande IdP-groepen en -rollen komt, sluit deze route aan op wat je al hebt ingericht voor andere applicaties.

De keerzijde is dat je niets kunt beheren zonder die SSO-basis. Op het vlak van identity providers noemt het supportartikel Okta als ondersteund, met meer identity providers die eraan komen. Gebruik je een andere identity provider, dan noemt het supportartikel die nog niet als ondersteund; de Claude-issued route heeft geen identity provider nodig, maar kent de beperkingen die hieronder staan.

Claude-issued: bèta en alleen een lidmaatschapscheck

Claude-issued auth is bèta. Claude geeft aan de connector door welke gebruiker bij Claude is ingelogd, onder een issuer-URL die uniek is voor de organisatie. Er is geen identity provider of SSO nodig en matching gebeurt op e-mailadres. Anthropic stuurt daarvoor het e-mailadres van elk lid plus een unieke identifier naar de connector.

De beveiligingsgrens staat letterlijk in de supporttekst:

"Claude checks organization membership only, not SSO, MFA, or the connector's own sign-in rules."

Praktisch gevolg: Claude-issued is een bruikbare tussenoplossing voor organisaties die snel willen uitrollen, maar het is geen vervanging voor IdP-beleid. Behandel het als een gemakkelijke route met een smallere controlebasis, niet als de strengere van de twee.

Wat je als admin bepaalt

De beheerdersrol is breed. Je kiest welke connectors zijn ingeschakeld en welke rollen ze krijgen. Daarbij kun je de ingebouwde rollen User, Admin, Owner en Primary owner als groep toewijzen, of custom roles individueel — bijvoorbeeld om eerst met één team te piloten. Ook bepaal je welke scopes Claude mag aanvragen.

Daarnaast kun je toegang intrekken. Bij IdP-managed betekent deprovisioning in de IdP dat de connectortoegang op hetzelfde moment verdwijnt. Bij Claude-issued stopt het signeren zodra iemand uit de Claude-organisatie wordt verwijderd, maar dan moet je die persoon ook uit de gekoppelde dienst verwijderen. Verder kun je afdwingen dat een connector alleen via managed authorization verbindt, zodat persoonlijke accounts buiten je werkgereedschap blijven.

Zo zet je het aan

De configuratie loopt via Organization settings > Connectors. Je selecteert een connector, gaat naar de Configuration-tab en kiest 'Set up' naast Managed authorization. Daarna volgt de keuze van de identiteitsbron, een Roles-stap, een Scopes-stap en tot slot 'Save & turn on'.

Voor de Claude-issued variant komt daar een stap bij: kopieer de issuer-URL en voeg die als trusted issuer toe in de adminconsole van de gekoppelde dienst. Optioneel plak je een tenant ID, waarna je 'Test connection' en 'Enable and continue' doorloopt. Anthropic adviseert twee of drie gebruikers te vragen te bevestigen dat de connector werkt voordat je de uitrol aankondigt. Dat is een kleine stap die veel supportvragen scheelt, vooral bij connectors waar matching op e-mailadres een rol speelt.

Offboarding en hergebruikte e-mailadressen

Het gevoeligste punt zit in offboarding. Claude signeert alleen voor huidige leden; op het moment dat je iemand verwijdert, blijft toegang die bij een dienst al is verleend doorlopen tot die verloopt. Verwijder de persoon daarom uit elke gekoppelde dienst voordat het e-mailadres opnieuw wordt gebruikt — anders kan een nieuwe persoon met dat adres worden ingelogd op het oude account.

Met SCIM verwijdert Claude een lid wanneer de directory die persoon verwijdert, maar niet wanneer de directory hem alleen suspendeert of inactief markeert. Dat onderscheid is precies waar het in de praktijk misgaat: een suspensie voelt als opruimen, maar laat de connector-toegang staan. Omdat access tokens die al zijn uitgegeven geldig blijven nadat iemand is verwijderd, bepaalt de levensduur van het access token hoe lang een verwijderde gebruiker toegang houdt. Koppel dat aan je bestaande praktijk voor API-sleutels en tokens veilig beheren, want dezelfde vragen over rotatie en looptijd komen hier terug.

Welke connectors meedoen

Via Enterprise-managed auth zijn deze connectors te voorzien: Amplitude, Apollo.io, Asana, Atlassian, Canva, Crossbeam, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Lovable, Mixpanel, Monday.com, Notion, PagerDuty, Semrush, Slack, Supabase en Unblocked. Niet elke connector ondersteunt de Claude-issued variant; die bèta werkt alleen bij providers die het ondersteunen. In de supportlijst zijn dat Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush en Supabase.

Wie een MCP-provider beheert die hier niet tussen staat: elke MCP-provider kan ondersteuning voor Enterprise-managed auth toevoegen, aldus de supportdocumentatie. De lijst is dus een momentopname. Voor de bredere ontwikkeling van het ecosysteem is de tracker van het MCP-ecosysteem met nieuwe servers en praktijkervaringen een bruikbare plek om te zien wie aansluit.

Hoe het technisch werkt: de MCP-extensie en ID-JAG

De IdP- en enterprise-managed route is de open MCP-extensie 'Enterprise-Managed Authorization' (io.modelcontextprotocol/enterprise-managed-authorization) op modelcontextprotocol.io. @ClaudeDevs noemt het "built on an open extension to MCP". In de flow ruilt de client een Identity Assertion JWT Authorization Grant (ID-JAG, een draft van de IETF OAuth-werkgroep) in voor een access token bij de authorization server van de MCP-server. Extensies zijn opt-in en nooit standaard actief.

De Claude-issued 'trusted issuer'-variant is een Anthropic-bèta bovenop dat model: Claude ondertekent de assertion onder https://identity.anthropic.com/issuers/<id>. Dat is niet de MCP-kernspecificatie, en de MCP-specificatie schrijft Claude niet voor als issuer. Houd dat onderscheid vast als je met leveranciers praat: de extensie is het gedeelde model, de trusted issuer is een invulling daarvan door één leverancier. De actuele stand van de specificatie volg je via de doorlopende tracker van de MCP-versiestand.

Wat connectorbouwers moeten regelen

Aan de kant van de connector verandert het een en ander. Een ondertekende JWT-identity-assertion vervangt het per-gebruiker OAuth-consentscherm. De authorization server moet de JWT bearer grant accepteren (RFC 7523). Dynamic Client Registration (DCR) wordt niet ondersteund in combinatie met Enterprise Managed Auth. Claude-issued assertions gebruiken ES256 en verlopen binnen een minuut.

Belangrijk voor de implementatie: een Claude-issued assertion "doesn't say that the user signed in through the customer's identity provider or used multi-factor authentication, and it carries no group claims". Servers moeten Claude-issued gebruikers daarom vinden op geverifieerd e-mailadres, niet op sub. De documentatie waarschuwt bovendien dat "An issuer URL isn't a secret". Access tokens die al zijn uitgegeven blijven geldig na verwijdering, dus de levensduur van het access token bepaalt hoe lang een verwijderde gebruiker toegang houdt. Ontwikkelaars die hun directory-vermelding willen laten markeren als ondersteunend, mailen naar [email protected].

Voor teams die zowel connectors bouwen als afnemen, is het handig de dagelijkse ontwikkelingen bij te houden via het dagelijkse MCP- en agent-toolingnieuws, want juist op het punt van issuer-vertrouwen en tokenlevensduur verschuift de praktijk snel.

Waarom dit telt voor beveiliging

De bredere context maakt duidelijk waarom dit soort details aandacht verdienen. De statuspagina van GitBook meldde op 3 november 2026 een aanval "using AI agents", waarbij om 19:00 CET op 2 november toegang tot infrastructuurcredentials werd verkregen; gebruikers van de GitBook MCP-server wordt gevraagd opnieuw te authenticeren en tokens te roteren. Daarnaast is een token-validatiekwetsbaarheid in de AWS API MCP Server opgelost in versie 1.6.0.

Dat zijn geen incidenten in de Claude-connectorfunctie, maar ze laten zien welk aanvalsoppervlak rond connectors en MCP-servers ligt: tokens, assertions en de vraag wie namens wie mag signeren. Labs schalen hun eigen beveiliging op, zoals blijkt uit OpenAI's securitysprint en bug bounties, en hoe OpenAI en Anthropic misbruik van hun modellen detecteren lees je in een eerder stuk. Dat agent-security vraagt om de aanname dat alles wat je agent leest aanvalsinput kan zijn, staat uitgewerkt in dit overzicht van agent-security. En wie de risico's van LLM-integraties in bredere zin wil wegen, vindt aanknopingspunten bij de analyse van AI-security voor bedrijven.

Als losse verwijzing, één regel: CrowdStrike kondigde op 3 november 2026 een AI Kill Switch aan in Falcon Guardian (eerst gateway, later endpoint), met agent-level hooks waaronder Claude Code, en draait zijn Falcon-sensor in de Claude Cowork VM in samenwerking met Anthropic.

Wat dit betekent voor teams in Nederland en Europa

De kern van de afweging is least privilege. Bij IdP-managed auth bepaalt je identity provider welke groepen en rollen toegang krijgen, en de gekoppelde dienst bepaalt welke permissies daarbij horen. Dat maakt het mogelijk om per team of per functie te scopen in plaats van per connector alles open te zetten. Bij Claude-issued auth is de check smaller — lidmaatschap van de Claude-organisatie — en ontbreken SSO-, MFA- en groepsclaims in de assertion. Kies de variant dus bewust per connector, niet als standaard.

Vanuit dataminimalisatie, als algemene duiding zonder nieuwe feiten: elke connector waarop je managed authorization inschakelt, is een plek waar identiteitsgegevens naartoe gaan. Bij Claude-issued stuurt Anthropic het e-mailadres en een unieke identifier per lid naar de connector. Beperk het aantal connectors tot wat je echt gebruikt, houd scopes zo nauw mogelijk en leg vast wat de bewaartermijn is. Voor Europese organisaties is dat ook de logische volgorde: eerst bepalen welke gegevens nodig zijn, dan welke identiteitsbron die gegevens mag overdragen.

Praktische checklist

• Bepaal per connector of je IdP-managed (GA) of Claude-issued (bèta) gebruikt; elke connector gebruikt er één tegelijk.
• Controleer of SSO aanstaat op Claude én op de connector voordat je IdP-managed inzet; Okta is ondersteund, meer identity providers komen eraan.
• Overweeg 'require managed authorization' zodat persoonlijke accounts buiten werkgereedschap blijven.
• Pilot eerst met één team via een custom role of de rol als groep, in plaats van met alle gebruikers tegelijk.
• Beperk de scopes die Claude mag aanvragen tot wat de use case vraagt.
• Bij Claude-issued: kopieer de issuer-URL naar de adminconsole van de dienst, test de verbinding en laat twee of drie gebruikers bevestigen dat het werkt.
• Regel offboarding in beide richtingen: verwijder mensen uit de Claude-organisatie én uit elke gekoppelde dienst.
• Let op SCIM-gedrag: verwijderen in de directory verwijdert het lid, suspenderen of inactief markeren niet.
• Stem de levensduur van access tokens af op je offboardingtermijn, en ruim e-mailadressen pas opnieuw in gebruik nadat de toegang is ingetrokken.
• Documenteer welke term je intern gebruikt: connectors in de beheeromgeving, plugins op X.

De aankondiging is in de eerste plaats een beheerfunctie, geen nieuwe connector. Wat je ermee wint, is dat de identiteit die je al hebt de toegang bepaalt in plaats van een reeks losse consent-schermen. Wat je ervoor moet regelen, is vooral discipline: één identiteitsbron per connector, scopes beperkt, en een offboardingpad dat verder gaat dan de Claude-organisatie.

Voor teams die vandaag willen beginnen, is de volgorde weinig spannend: eerst IdP-managed waar SSO rond is, dan een pilot met Claude-issued voor de connectors waar de bèta het ondersteunt, en ondertussen de offboarding controleren. Wie de bredere ontwikkelingen wil volgen, kan de MCP-trackers in de gaten houden; de lijst met ondersteunde connectors is een momentopname en elke MCP-provider kan aansluiten.

Gecontroleerd op 2026-11-04.

Dit bericht is samengesteld met AI-ondersteuning en redactioneel gecontroleerd; bronnen staan hieronder.

Bronnen

• Anthropic supportartikel 'Auto-connect your organization's apps to Claude', met de configuratiestappen, rollen, scopes, offboarding en de connectorlijsten — https://support.claude.com/en/articles/15537633-auto-connect-your-organization-s-apps-to-claude
• Anthropic documentatie voor connectorbouwers over Enterprise Managed Auth (JWT-assertions, RFC 7523, ES256, e-mailmatching, issuer-URL) — https://claude.com/docs/connectors/building/enterprise-managed-auth
• MCP-extensie 'Enterprise-Managed Authorization' met ID-JAG — https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization
• Bericht van @ClaudeDevs over de functie en de open MCP-extensie (3 november 2026) — https://x.com/ClaudeDevs/status/2117680635561312732
• Bericht van Boris Cherny (@bcherny) waarin dezelfde functionaliteit 'plugins' wordt genoemd — https://x.com/bcherny/status/2117693181651542387
• GitBook statuspagina over het security-incident van 3 november 2026, met het verzoek de MCP-server opnieuw te authenticeren en tokens te roteren — https://www.gitbook.com/status/security-incident-2026-11-03