Gå igenom vår sida ”SSO-översikt” för att bekanta dig med de centrala begrepp som diskuteras i det här dokumentet.
Innan du verifierar dina domäner är det viktigt att överväga några olika frågor:
Hur vill du tillhandahålla inbjudningar till nya användare?
Hur vill du hantera befintliga konsumentanvändare (Personal/Plus/Pro)?
Hur vill du att inloggningsflödet för användare ska se ut?
Vi går igenom var och en av dessa frågor mer i detalj för att hjälpa dig att välja det alternativ som bäst passar dina behov.
Bjuda in nya användare
Vi erbjuder för närvarande fyra olika metoder för att tillhandahålla inbjudningar till användare:
Det är värt att notera att vi skiljer mellan fall där inbjudningsmejl skickas aktivt och fall där en inbjudan kopplas tyst till en användares e-postadress i vårt backend-system.
Inbjudningsmejl skickas aktivt när:
En ny användare bjuds in för första gången via SCIM.
En användare bjuds in direkt från ChatGPT eller API Platform.
Inbjudningar kopplas tyst när:
En SCIM-användare togs bort från din IdP-grupp och lades sedan till igen.
Automatiskt kontoskapande gäller.
I det senare fallet ser användarna inte inbjudningarna i sin inkorg, men de dirigeras ändå korrekt till motsvarande arbetsyta eller organisation när de försöker logga in.
SCIM
SCIM finns tillgängligt i både ChatGPT och API Platform. SCIM gör det möjligt för identitetsleverantörer (t.ex. Okta, Entra ID osv.) att utbyta användaridentitetsdata med OpenAI och automatisera tillhandahållandet av inbjudningar (och avetablering av användarkonton) utifrån organisatoriska förändringar.
Även om SCIM också konfigureras via din IdP kan det konfigureras oberoende av SSO. Därför är domänverifiering och SSO inte krav för SCIM.
Om du bestämmer dig för att använda både SCIM och SSO är den viktiga skillnaden att:
SCIM tillhandahåller endast inbjudningar
SSO hanterar autentisering och användarskapande
Vi anser att SCIM är den mest robusta och skalbara lösningen för övergripande användarhantering. Beroende på din idealiska implementering rekommenderar vi i allmänhet följande arkitektur som bästa praxis om du distribuerar över både ChatGPT och API Platform:
Med den här konfigurationen kan du enkelt hantera både inbjudningar och åtkomst (till ChatGPT och API Platform) separat. Den här konfigurationen har dessutom fördelen att alla nödvändiga ändringar kan göras centralt av dina administrationsteam direkt i din IdP.
Om du implementerar SCIM i flera olika applikationer (dvs. ChatGPT jämfört med API Platform och andra konton) bör dina SCIM-applikationer vara unika. Även om målgruppen är identisk rekommenderar vi starkt att varje SCIM-implementering refererar till en unik applikation i din IdP.
Om du inte uppfyller detta krav kan det leda till inkonsekvenser som i slutändan resulterar i ogiltiga medlemskap.
Direkta inbjudningar från ChatGPT eller API Platform
Administratörer kan bjuda in användare direkt via e-post från respektive sida ChatGPT och Platform ”Medlemmar”. I ChatGPT stöder den här metoden även massinbjudningar via en uppladdad CSV-fil:
Även om det vanligtvis inte är skalbart rekommenderar vi ofta direkta inbjudningar när du kommer igång med en ny arbetsyta eller organisation. Till skillnad från SCIM finns det ingen potentiell fördröjning innan inbjudningarna når användarnas inkorgar, så det är det mest effektiva alternativet för snabb åtkomst, ändring av behörigheter och allmän testning.
Dessutom kan du alltid aktivera SCIM längre fram och placera dina befintliga användare under SCIM-applikationen. Det finns alltså ingen risk att direktinbjudna användare utesluts från framtida automatisering, om det inte är önskvärt.
Automatiskt kontoskapande (AAC)
Till skillnad från de andra alternativen är AAC endast tillgängligt på identitetssidan i ChatGPT och kräver att SSO först har aktiverats:
Som visas ovan säkerställer AAC att användare som registrerar sig eller loggar in med en verifierad e-postdomän automatiskt läggs till i din Enterprise-arbetsyta. Användarna får inget inbjudningsmejl, och processen är helt automatiserad. Detta har både för- och nackdelar.
Om din policy är att ge fri åtkomst till alla användare med din verifierade domän är AAC ett bra alternativ som undviker det extra arbetet med att konfigurera och hantera en SCIM-applikation.
AAC är dock inte idealiskt om du behöver en mer låst, godkännandebaserad modell för användaråtkomst.
⚠️ VARNING ⚠️
Det är viktigt att komma ihåg att aktivering av AAC i praktiken tvingar alla konsumentanvändare (Personal/Plus/Pro) under din domän att slås samman med din Enterprise-arbetsyta. Mer om detta finns nedan i avsnittet ”Hantera befintliga användare”.
Observera att även om användarna inte är medlemmar i din IdP-åtkomstgrupp och inte kan komma åt arbetsytan om SSO är tvingande, tar de ändå upp en plats i ditt Enterprise-konto i det här scenariot.
Av den anledningen rekommenderar vi i de flesta fall SCIM eller direkta inbjudningar i stället för AAC. För att undvika möjliga missförstånd rekommenderar vi också att du låter AAC vara avstängt om du planerar att använda SCIM.
API Platform Admin Invites endpoint
Vår API Platform har stöd för en Invites endpoint, som gör att du programmatiskt kan bjuda in användare till din API-organisation.
Jämfört med SCIM är den stora fördelen med endpoint att den låter dig ange vilket eller vilka projekt den inbjudna användaren ska tillhöra:
Det ger ytterligare granularitet och kontroll, utan att kräva det manuella arbetet med enskilda direktinbjudningar.
Hantera befintliga konsumentanvändare
Vi definierar konsumentanvändare som användare med en Personal-, Plus- eller Pro-prenumeration. Det är vanligt att det finns befintliga konsumentanvändare med din verifierade domän som hade konton innan ditt Enterprise-avtal. Eftersom verifiering av domänen och aktivering av SSO kan få följdeffekter för dessa konsumentanvändare är det viktigt att avgöra önskat resultat i förväg.
Påverkan på ChatGPT-konsumentanvändare
På ChatGPT-sidan avgörs påverkan på konsumenter främst av två faktorer:
Kommer de att bjudas in till Enterprise-arbetsytan?
Kommer du att kräva SSO?
Det resulterande beteendet visas nedan:
| Väntande inbjudan? | SSO krävs? | Resultat |
|---|---|---|
| Ja | Ja | Konsumentanvändarkonton tvingas slås samman med Enterprise och kan bara logga in med SSO. |
| Ja | Nej | Konsumentanvändarkonton tvingas slås samman med Enterprise, och användarna kan autentisera sig med SSO eller social inloggning. |
| Nej | Ja | Ingen påverkan: Konsumentanvändare behåller åtkomst till sina personliga arbetsytor via lösenord eller social autentisering. |
| Nej | Nej | Ingen påverkan: Konsumentanvändare behåller åtkomst till sina personliga arbetsytor via lösenord eller social autentisering. |
Om ditt mål är att i slutändan förhindra alla konsumentkonton bör du kontakta din Account Director för att diskutera möjliga alternativ.
Kontosammanslagning
Förutsättningarna för att utlösa en automatisk sammanslagning av konsumentkontot med ett Enterprise-konto är följande:
Användarens domän är verifierad.
Användaren har fått en inbjudan till den Enterprise-arbetsyta där domänen är verifierad.
Obs! Om du har aktiverat AAC är detta villkor alltid uppfyllt för alla användare med din verifierade domän.
När dessa villkor är uppfyllda bör användaren se följande modal nästa gång hen loggar in i eller uppdaterar ChatGPT:
Som bilden visar återbetalar vi automatiskt eventuella befintliga Plus- eller Pro-prenumerationer före sammanslagningen. Användare kan välja att överföra sin befintliga chatthistorik och sina GPT:er, eller exportera chatthistoriken via e-post och börja i sin Enterprise-arbetsyta med ett ”rent blad”.
Obs! Om mål-Arbetsytan för Enterprise eller Edu har Datahemvist aktiverat kan data från den personliga Arbetsytan inte överföras. Användare kan endast exportera sina chattar och ta bort den personliga Arbetsytan. Mer information finns i E-postinbjudningar och kontomigreringar.
När konsumentkontot har slagits samman går det inte att återställa det. Om dina användare valde alternativet ”Överför befintlig chatthistorik och GPT:er” men inte såg detta återspeglas i sin Enterprise-arbetsyta ber vi dig kontakta supporten.
Påverkan på konsumentanvändare i API Platform
Eftersom SSO på Platform fortfarande är domänbaserat (till skillnad från ChatGPT, där SSO är specifikt för den arbetsyta där det har aktiverats) påverkas dina konsumentanvändare så snart du verifierar din domän och aktiverar SSO för valfri organisation.
Konsumentanvändarna förlorar möjligheten att autentisera sig med lösenord, eftersom vi identifierar domänmatchningen och vidarebefordrar dem till din IdP. Om de är medlemmar i din IdP kan de autentisera sig utan problem. Alternativt kan de logga in med ett socialt OAuth-alternativ om det är tillgängligt för dem. Om inte har du i praktiken låst dem ute från deras konsumentkonton.
Se avsnittet Flöde för användarinloggning för en mer ingående guide till det här arbetsflödet.
Rekommenderade mönster för identitet och tillhandahållande
Nu när vi har gått igenom det grundläggande beteendet kopplat till identitetsautentisering och tillhandahållande av inbjudningar kan det vara bra att se över några av de vanligaste implementeringsmönstren som är tillgängliga för Enterprise-användare:
Flöde för användarinloggning
Vi har redan gått igenom effekten av väntande inbjudningar och tvingande SSO, så det här avsnittet hjälper till att visualisera det förväntade flödet och de kontroller vi gör när en användare anger sin e-postadress för att logga in.
Inloggningsflöde för ChatGPT
Obs! Det här diagrammet omfattar inte inloggningsförsök via en social metod eller via Tile-URL:en.
Inloggningsflöde för API Platform
Obs! Det här diagrammet omfattar inte inloggningsförsök via en social metod eller via Tile-URL:en.
Nästa steg
Nu när du har en bild av din idealiska implementering kan du följa respektive dokumentation för att aktivera SCIM eller SSO: