ServiceLogin

ServiceLogin ist die Konfiguration, mit der ein Space die Endnutzer (ServiceUser) seines eigenen Produkts per OAuth registriert und anmeldet. Sie ist der Einstiegspunkt, um dem Produkt ein vom Weegloo-Plattformkonto (dem Weegloo User, der sich im Content-Studio anmeldet) getrenntes Identitätssystem anzubinden. Ein über diese Konfiguration registriertes Mitglied erhält die Standardrolle (defaultRole) der ServiceLogin, und das Token dieses Mitglieds authentifiziert sich gegenüber ACMA/ACDA.

In einem Space existiert höchstens eine ServiceLogin. Wird die Erstellung (POST) erneut aufgerufen, während bereits eine vorhanden ist, wird WGL409003 (409 Conflict) zurückgegeben. Daher ruft auch die Abfrage diese eine ohne loginId über GET .../service-login als Einzelressource ab (es gibt keinen Listenendpunkt).

Ressourcenstruktur

Im Folgenden steht die Antwort für eine einzelne ServiceLogin. Zusammen mit sys (Systemeigenschaften) besitzt sie die Hauptattribute name, callbackUrl, contactEmail und approvalRequired, die die Anzeigeinformationen des Dienstes und das Registrierungsverhalten enthalten.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSlgn01Ex",
    "type": "ServiceLogin",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "defaultRole": { "sys": { "id": "3trmXRLXeZN2RTHvVj3hFDN5546vbp", "type": "Refer", "targetType": "ServiceUserRole" } },
    "providers": [
      { "registrationId": "google", "clientId": "821047-dailywear.apps.googleusercontent.com" }
    ],
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T12:55:00.000Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T12:55:00.000Z",
    "version": 1
  },
  "name": "DailyWear Mitgliedschaft",
  "callbackUrl": "https://dailywear.example/auth/callback",
  "contactEmail": "members@dailywear.example",
  "approvalRequired": false
}

Wichtigste Schlüssel:

• defaultRole: der Refer auf die ServiceUserRole, die ein neu registriertes Mitglied standardmäßig erhält. Wird für ein einzelnes Mitglied eine abweichende Rolle benötigt, wird sie über roleOverride des ServiceUser überschrieben.
• providers: die Liste der OAuth-Anbieter, die dieser Dienst unterstützt. Jeder Eintrag besteht aus registrationId, clientId und clientSecret. In der Antwort erscheint clientSecret nicht.
• callbackUrl: die URL, zu der ein Mitglied nach Abschluss der OAuth-Anmeldung weitergeleitet wird. An diese URL wird das Austausch-Token (exchangeToken) als Querystring angehängt zurückgegeben.
• approvalRequired: wenn aktiviert, wird ein neues Mitglied mit deaktivierter Anmeldung (enableLogin=false) registriert und benötigt die Freigabe durch einen Administrator.

Systemeigenschaften (sys)

Jede ServiceLogin enthält die gemeinsamen Systemeigenschaften im sys-Objekt. space, defaultRole, createdBy und updatedBy liegen in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) vor.

ServiceLogin ist eine Konfigurationsressource und kennt daher kein Veröffentlichungskonzept. Es gibt kein publish, archive oder status, sondern nur version zur Vermeidung von Konflikten bei gleichzeitiger Änderung.

Hauptattribute und Provider

providers

providers ist die Liste der OAuth-Anbieter, die dieser Dienst unterstützt. Jeder Provider besteht aus den folgenden drei Werten.

Derzeit hat WEEGLOO OAuth-Endpunkte für sieben registrationId-Werte angebunden: google, github, facebook, gitlab, kakao, naver und line. Mit anderen Werten funktioniert die Anmeldung nicht.

Ein Provider kann sowohl im Erstellungs-Body der ServiceLogin mitgegeben als auch über die untenstehenden Endpunkte zum Hinzufügen, Ändern und Löschen von Providern separat verwaltet werden. Da der Änderungs-Body (PUT) der ServiceLogin kein providers enthält, werden die Provider einer bereits erstellten Konfiguration über die dafür vorgesehenen Endpunkte behandelt.

Eine ServiceLogin muss immer mindestens einen Provider haben und darf höchstens 10 haben. Bei der Erstellung muss mindestens einer in providers angegeben werden. Der letzte verbleibende Provider kann nicht gelöscht werden; ein Löschversuch gibt WGL422055 (422) zurück. Um alle Provider zu entfernen, löschen Sie die ServiceLogin selbst.

Redirect-URI registrieren

Wenn Sie in der Konsole eines Providers (Google, GitHub, Facebook, GitLab, Kakao, Naver, LINE) eine OAuth-App anlegen, müssen Sie die autorisierte Redirect-URI (redirect URI) genau so registrieren, wie WEEGLOO sie verwendet. Bei abweichenden Werten schlägt die Anmeldung mit redirect_uri mismatch fehl.

Die zu registrierende URI hat das folgende Format.

https://auth.weegloo.com/v1/spaces/{spaceId}/login/oauth2/code/{registrationId}

• {spaceId}: die sys.id des Space, zu dem diese ServiceLogin gehört.
• {registrationId}: die Provider-Kennung (google, github, facebook, gitlab, kakao, naver, line).

Wenn Sie zum Beispiel Google an den Space HnQ32YiH anbinden, registrieren Sie https://auth.weegloo.com/v1/spaces/HnQ32YiH/login/oauth2/code/google.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Header Authorization ist ein Bearer-Token erforderlich, das CMA authentifiziert. Die Änderungsendpunkte (PUT, PATCH) und die Provider-Verwaltungsendpunkte müssen die aktuelle sys.version im Header X-Weegloo-Version mitführen, um Konflikte bei gleichzeitiger Änderung zu verhindern. Bei der Erstellung und beim Löschen der ServiceLogin gibt es diesen Header nicht. Die Abfrage ruft ohne loginId die eine ServiceLogin dieses Space ab.

Verwandte Dokumente

• ServiceUserRole: das Berechtigungsbündel, das über defaultRole vergeben wird.
• ServiceUser: die über diese Konfiguration registrierten Mitglieder.
• Auth-API: der Ablauf der OAuth-Anmeldung und des Token-Austauschs für Mitglieder.