Authentifizierung zu deiner Angular-Anwendung hinzufügen (Add authentication to your Angular application)

Diese Anleitung zeigt dir, wie du das Logto Angular SDK v2 in deine Anwendung integrierst.

tipp:

Diese Anleitung verwendet das offizielle @logto/angular v2 SDK, das Angular 20 unterstützt und Dependency Injection sowie Signals bereitstellt.
Das Beispielprojekt ist in unserem SDK-Repository verfügbar.

Voraussetzungen

Ein Logto Cloud Konto oder ein selbst gehostetes Logto.
Eine Single-Page-Anwendung (SPA), die in der Logto Console erstellt wurde.
Ein Angular 20 Projekt.

Installation

Installiere das Logto SDK über deinen bevorzugten Paketmanager:

npm
pnpm
yarn

npm i @logto/angular

pnpm add @logto/angular

yarn add @logto/angular

Integration

Logto-Provider initialisieren

Registriere in deinem Angular-Projekt provideLogto und deine Anwendungsrouten in app.config.ts:

app/app.config.ts
// Registriere Logto und die Routen in der Angular-Konfiguration
import { type ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideLogto } from '@logto/angular';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
    }),
    provideRouter(routes),
    // ...weitere Provider
  ],
};

provideLogto stellt den Authentifizierungsstatus nach dem ersten Rendern im Browser automatisch wieder her. Du musst in deinen Komponenten keine Initialisierungsmethode aufrufen.

hinweis:

Bei der Verwendung von Server-Side Rendering (SSR) sind Authentifizierungsstatus und Tokens nur im Browser verfügbar. Verwende isLoading(), um einen Ladezustand anzuzeigen, bis die Initialisierung abgeschlossen ist. Wenn du authentifizierte Daten während des Server-Renderings benötigst, verwende ein Server- oder BFF-SDK.

Redirect-URIs konfigurieren

Bevor wir ins Detail gehen, hier ein schneller Überblick über die Endbenutzererfahrung. Der Anmeldeprozess lässt sich wie folgt vereinfachen:

Deine App löst die Anmeldemethode aus.
Der Benutzer wird auf die Logto-Anmeldeseite umgeleitet. Bei nativen Apps wird der Systembrowser geöffnet.
Der Benutzer meldet sich an und wird zurück zu deiner App umgeleitet (konfiguriert als Redirect-URI).

Dieser Authentifizierungsprozess folgt dem OpenID Connect (OIDC) Protokoll, und Logto erzwingt strenge Sicherheitsmaßnahmen, um die Benutzeranmeldung zu schützen.
Wenn du mehrere Apps hast, kannst du denselben Identitätsanbieter (Logto) verwenden. Sobald sich der Benutzer bei einer App anmeldet, wird Logto den Anmeldeprozess automatisch abschließen, wenn der Benutzer auf eine andere App zugreift.

Um mehr über die Gründe und Vorteile der umleitungsbasierten Anmeldung zu erfahren, siehe Logto-Anmeldeerfahrung erklärt.

hinweis:

In den folgenden Code-Snippets gehen wir davon aus, dass deine App unter http://localhost:3000/ läuft.

Redirect-URIs konfigurieren

Wechsle zur Anwendungsdetailseite der Logto-Konsole. Füge eine Redirect-URI http://localhost:3000/callback hinzu.

Genau wie beim Anmelden sollten Benutzer zu Logto weitergeleitet werden, um sich von der gemeinsamen Sitzung abzumelden. Sobald dies abgeschlossen ist, wäre es ideal, den Benutzer zurück zu deiner Website zu leiten. Füge zum Beispiel http://localhost:3000/ als Redirect-URI nach dem Abmelden hinzu.

Klicke dann auf "Speichern", um die Änderungen zu speichern.

Redirect behandeln

Erstelle eine Callback-Komponente, um die Anmeldung abzuschließen, nachdem Logto den Benutzer zurück zu deiner Anwendung umgeleitet hat. Verwende afterNextRender, damit die Callback-Verarbeitung nur im Browser ausgeführt wird:

app/callback.component.ts
// Callback-Komponente zur Verarbeitung der Rückleitung nach der Anmeldung
import { afterNextRender, Component, inject } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-callback',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    } @else {
      <p>Anmeldung wird abgeschlossen...</p>
    }
  `,
})
export class CallbackComponent {
  readonly logto = inject(LogtoService);

  constructor() {
    afterNextRender(() => {
      void (async () => {
        const callbackUri = window.location.href;

        if (!(await this.logto.isSignInRedirected(callbackUri))) {
          window.location.replace(window.location.origin);
          return;
        }

        await this.logto.handleSignInCallback(callbackUri);
      })().catch(() => {
        // Das SDK gibt Callback-Fehler über logto.error() für das Template aus.
      });
    });
  }
}

isSignInRedirected() prüft, ob die URL zu einer aktiven Anmeldesitzung passt. Wenn jemand die Callback-Route ohne eine solche Sitzung aufruft, leitet dieses Beispiel stattdessen auf die Startseite der Anwendung zurück, anstatt die Anmeldung abzuschließen.

Registriere die Callback-Route in app.routes.ts. Sie muss mit dem Pfad deiner Redirect-URI übereinstimmen und darf keine Authentifizierung erfordern. Verwende zum Beispiel callback für eine Redirect-URI, die mit /callback endet:

app/app.routes.ts
// Registrierung der Callback-Route
import { type Routes } from '@angular/router';

import { CallbackComponent } from './callback.component';

export const routes: Routes = [
  { path: 'callback', component: CallbackComponent },
  // ...weitere Routen
];

Die Root-Komponente benötigt ein <router-outlet />, um diese Route zu rendern, wie im nächsten Schritt gezeigt.

Injiziere LogtoService, um die Anmeldung und Abmeldung zu starten. Übergebe die registrierten Redirect-URIs an diese Methoden. Die postRedirectUri gibt dem SDK an, wohin nach erfolgreicher Verarbeitung des Anmelde-Callbacks navigiert werden soll:

hinweis:

Bevor du signIn() aufrufst, stelle sicher, dass du die Redirect-URI im Admin Console korrekt konfiguriert hast.

app/app.component.ts
// Anmeldung und Abmeldung in der Hauptkomponente implementieren
import { Component, inject } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet],
  templateUrl: './app.component.html',
})
export class AppComponent {
  readonly logto = inject(LogtoService);

  async signIn() {
    await this.logto.signIn({
      redirectUri: 'http://localhost:3000/callback',
      postRedirectUri: window.location.origin,
    });
  }

  async signOut() {
    await this.logto.signOut('http://localhost:3000/');
  }
}

Lese die isLoading(), isAuthenticated() und error() Signale direkt im Template aus:

app/app.component.html
@if (logto.error(); as error) {
<p role="alert">{{ error.message }}</p>
} @if (logto.isLoading()) {
<p>Lädt...</p>
} @else if (logto.isAuthenticated()) {
<button type="button" (click)="signOut()">Abmelden</button>
} @else {
<button type="button" (click)="signIn()">Anmelden</button>
}

<router-outlet />

Halte <router-outlet /> außerhalb der Authentifizierungsbedingungen, damit der Callback gerendert werden kann, bevor der Benutzer angemeldet ist.

Das Aufrufen von .signOut() wird alle Logto-Daten im Speicher und im localStorage löschen, falls sie vorhanden sind.

Checkpoint: Teste deine Anwendung

Jetzt kannst du deine Anwendung testen:

Starte deine Anwendung, du wirst den Anmeldebutton sehen.
Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
Klicke auf den Abmeldebutton, um den Token-Speicher zu leeren und dich abzumelden.

Benutzerinformationen abrufen

Benutzerinformationen anzeigen

Um die Informationen des Benutzers anzuzeigen, verwende getIdTokenClaims(), um Ansprüche (Claims) aus dem ID-Token ohne zusätzliche Netzwerkabfrage auszulesen. Füge deiner AppComponent einen effect hinzu, um die Ansprüche zu laden, sobald isAuthenticated() wahr wird, auch wenn eine bestehende Sitzung wiederhergestellt wird. Importiere JsonPipe, um das Ergebnis anzuzeigen:

app/app.component.ts
// Importiere JsonPipe, um das Ergebnis als JSON anzuzeigen
import { JsonPipe } from '@angular/common';
import { Component, effect, inject, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { LogtoService, type IdTokenClaims } from '@logto/angular';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [JsonPipe, RouterOutlet],
  templateUrl: './app.component.html',
})
export class AppComponent {
  readonly logto = inject(LogtoService);
  readonly user = signal<IdTokenClaims | undefined>(undefined);

  constructor() {
    effect(() => {
      if (!this.logto.isAuthenticated()) {
        this.user.set(undefined);
        return;
      }

      void this.logto
        .getIdTokenClaims()
        .then((claims) => {
          this.user.set(claims);
        })
        .catch(() => {
          // Das SDK gibt den Fehler über logto.error() für das Template aus.
        });
    });
  }

  // ...behalte die Methoden signIn() und signOut() aus dem vorherigen Schritt bei
}

Füge Folgendes innerhalb des logto.isAuthenticated()-Zweigs deines Templates hinzu:

app/app.component.html
@if (user(); as claims) {
<pre>{{ claims | json }}</pre>
}

Zusätzliche Ansprüche anfordern

Möglicherweise fehlen einige Benutzerinformationen im zurückgegebenen Objekt von getIdTokenClaims(). Dies liegt daran, dass OAuth 2.0 und OpenID Connect (OIDC) so konzipiert sind, dass sie dem Prinzip der minimalen Rechte (PoLP) folgen, und Logto auf diesen Standards basiert.

Standardmäßig werden begrenzte Ansprüche zurückgegeben. Wenn du mehr Informationen benötigst, kannst du zusätzliche Berechtigungen anfordern, um auf mehr Ansprüche zuzugreifen.

info:

Ein "Anspruch (Claim)" ist eine Behauptung über ein Subjekt; eine "Berechtigung (Scope)" ist eine Gruppe von Ansprüchen. Im aktuellen Fall ist ein Anspruch ein Informationsstück über den Benutzer.

Hier ist ein nicht-normatives Beispiel für die Beziehung zwischen Berechtigung und Anspruch:

tipp:

Der "sub"-Anspruch bedeutet "Subjekt", was der eindeutige Identifikator des Benutzers ist (d. h. Benutzer-ID).

Das Logto SDK wird immer drei Berechtigungen anfordern: openid, profile und offline_access.

Füge die Berechtigungen (Scopes) zu deiner provideLogto-Konfiguration hinzu:

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto, UserScope } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: [
        UserScope.Email,
        UserScope.Phone,
        UserScope.CustomData,
        UserScope.Identities,
        UserScope.Organizations,
      ],
    }),
    // ...weitere Provider
  ],
};

Melde dich nach der Änderung der Berechtigungen erneut an. Die zusätzlichen ID-Token-Ansprüche wie email und phone_number sind dann über getIdTokenClaims() verfügbar und werden wie oben im Beispiel angezeigt.

Ansprüche, die Netzwerk-Anfragen benötigen

Um das ID-Token nicht aufzublähen, erfordern einige Ansprüche Netzwerk-Anfragen, um abgerufen zu werden. Zum Beispiel ist der custom_data Anspruch nicht im Benutzerobjekt enthalten, selbst wenn er in den Berechtigungen angefordert wird. Um auf diese Ansprüche zuzugreifen, kannst du die fetchUserInfo() Methode verwenden:

app/app.component.ts
// Füge diese Methode zur AppComponent hinzu und rufe sie nach der Anmeldung auf.
async loadUserInfo() {
const userInfo = await this.logto.fetchUserInfo();
// Jetzt kannst du auf userInfo.custom_data, userInfo.identities usw. zugreifen.
return userInfo;
}

Diese Methode wird die Benutzerinformationen abrufen, indem sie eine Anfrage an den Userinfo-Endpunkt stellt. Um mehr über die verfügbaren Berechtigungen und Ansprüche zu erfahren, siehe den Berechtigungen und Ansprüche Abschnitt.

fetchUserInfo() kann zusammen mit API-Ressourcen-Zugangstokens verwendet werden. Die Konfiguration von resources verhindert nicht, dass das SDK Benutzerinformationen anfordert.

Berechtigungen und Ansprüche

Logto verwendet die OIDC Scopes- und Claims-Konventionen, um die Berechtigungen (Scopes) und Ansprüche (Claims) für das Abrufen von Benutzerinformationen aus dem ID-Token und dem OIDC userinfo-Endpunkt zu definieren. Sowohl „Berechtigung (Scope)“ als auch „Anspruch (Claim)“ sind Begriffe aus den OAuth 2.0- und OpenID Connect (OIDC)-Spezifikationen.

Für Standard-OIDC-Ansprüche wird die Aufnahme in das ID-Token strikt durch die angeforderten Berechtigungen bestimmt. Erweiterte Ansprüche (wie custom_data und organizations) können zusätzlich so konfiguriert werden, dass sie im ID-Token über die Custom ID token-Einstellungen erscheinen.

Hier ist die Liste der unterstützten Berechtigungen (Scopes) und der entsprechenden Ansprüche (Claims):

Standard OIDC-Berechtigungen (Scopes)

openid (Standard)

Claim-Name	Typ	Beschreibung
sub	`string`	Der eindeutige Identifikator des Benutzers

profile (Standard)

Claim-Name	Typ	Beschreibung
name	`string`	Der vollständige Name des Benutzers
username	`string`	Der Benutzername des Benutzers
picture	`string`	URL zum Profilbild des Endbenutzers. Diese URL MUSS auf eine Bilddatei (z. B. PNG, JPEG oder GIF) verweisen, nicht auf eine Webseite mit einem Bild. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das zur Darstellung des Endbenutzers geeignet ist, und nicht auf ein beliebiges vom Endbenutzer aufgenommenes Foto.
created_at	`number`	Zeitpunkt, zu dem der Endbenutzer erstellt wurde. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.
updated_at	`number`	Zeitpunkt, zu dem die Informationen des Endbenutzers zuletzt aktualisiert wurden. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.

Weitere Standard-Ansprüche (Claims) wie family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo und locale werden ebenfalls im profile-Scope enthalten sein, ohne dass der userinfo-Endpunkt angefragt werden muss. Ein Unterschied zu den oben genannten Claims besteht darin, dass diese Claims nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die oben genannten Claims null zurückgeben, wenn die Werte leer sind.

hinweis:

Im Gegensatz zu den Standard-Claims verwenden die Claims created_at und updated_at Millisekunden anstelle von Sekunden.

email

Claim-Name	Typ	Beschreibung
email	`string`	Die E-Mail-Adresse des Benutzers
email_verified	`boolean`	Ob die E-Mail-Adresse verifiziert wurde

phone

Claim-Name	Typ	Beschreibung
phone_number	`string`	Die Telefonnummer des Benutzers
phone_number_verified	`boolean`	Ob die Telefonnummer verifiziert wurde

address

Bitte siehe die OpenID Connect Core 1.0 für Details zum Address-Claim.

info:

Scopes, die mit (Standard) gekennzeichnet sind, werden immer vom Logto SDK angefordert. Claims unter den Standard-OIDC-Scopes sind immer im ID-Token enthalten, wenn der entsprechende Scope angefordert wird — sie können nicht deaktiviert werden.

Erweiterte Berechtigungen (Scopes)

Die folgenden Scopes sind von Logto erweitert und liefern Claims über den userinfo-Endpunkt. Diese Claims können auch so konfiguriert werden, dass sie direkt im ID-Token enthalten sind, über Konsole > Benutzerdefiniertes JWT. Siehe Benutzerdefiniertes ID-Token für weitere Details.

custom_data

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
custom_data	`object`	Die benutzerdefinierten Daten des Benutzers

identities

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
identities	`object`	Die verknüpften Identitäten des Benutzers
sso_identities	`array`	Die verknüpften SSO-Identitäten des Benutzers

roles

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
roles	`string[]`	Die Rollen (Roles) des Benutzers	✅

urn:logto:scope:organizations

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
organizations	`string[]`	Die Organisations-IDs, denen der Benutzer angehört	✅
organization_data	`object[]`	Die Organisationsdaten, denen der Benutzer angehört

hinweis:

Diese Organisations-Claims können auch über den userinfo-Endpunkt abgerufen werden, wenn ein opaker Token verwendet wird. Allerdings können opake Tokens nicht als Organisationstoken für den Zugriff auf organisationsspezifische Ressourcen verwendet werden. Siehe Opaker Token und Organisationen für weitere Details.

urn:logto:scope:organization_roles

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
organization_roles	`string[]`	Die Organisationsrollen, denen der Benutzer angehört, im Format `<organization_id>:<role_name>`	✅

API-Ressourcen

Wir empfehlen, zuerst 🔐 Rollenbasierte Zugangskontrolle (RBAC) zu lesen, um die grundlegenden Konzepte von Logto RBAC zu verstehen und wie man API-Ressourcen richtig einrichtet.

Logto-Client konfigurieren

Sobald du die API-Ressourcen eingerichtet hast, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    }),
    // ...other providers
  ],
};

Jede API-Ressource hat ihre eigenen Berechtigungen (Berechtigungen).

Zum Beispiel hat die Ressource https://shopping.your-app.com/api die Berechtigungen shopping:read und shopping:write, und die Ressource https://store.your-app.com/api hat die Berechtigungen store:read und store:write.

Um diese Berechtigungen anzufordern, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    }),
    // ...other providers
  ],
};

Du wirst bemerken, dass Berechtigungen separat von API-Ressourcen definiert sind. Dies liegt daran, dass Resource Indicators for OAuth 2.0 spezifiziert, dass die endgültigen Berechtigungen für die Anfrage das kartesische Produkt aller Berechtigungen bei allen Zielservices sein werden.

Somit können im obigen Fall die Berechtigungen aus der Definition in Logto vereinfacht werden, beide API-Ressourcen können read und write Berechtigungen ohne Präfix haben. Dann, in der Logto-Konfiguration:

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: ['read', 'write'], // Berechtigungen
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // API-Ressourcen
    }),
    // ...other providers
  ],
};

Für jede API-Ressource wird sowohl read als auch write Berechtigungen angefordert.

hinweis:

Es ist in Ordnung, Berechtigungen anzufordern, die in den API-Ressourcen nicht definiert sind. Zum Beispiel kannst du die Berechtigung email anfordern, auch wenn die API-Ressourcen die Berechtigung email nicht verfügbar haben. Nicht verfügbare Berechtigungen werden sicher ignoriert.

Nach der erfolgreichen Anmeldung wird Logto die entsprechenden Berechtigungen an API-Ressourcen gemäß den Rollen des Benutzers ausstellen.

Melde dich nach Änderungen an den Ressourcen oder Berechtigungen erneut an, damit der Benutzer die aktualisierte Konfiguration autorisieren kann.

Zugangstoken für die API-Ressource abrufen

Um das Zugangstoken für eine spezifische API-Ressource abzurufen, kannst du die Methode getAccessToken() verwenden:

app/api-resource.component.ts
import { Component, inject, signal } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-api-resource',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    }
    @if (logto.isAuthenticated()) {
      <button type="button" [disabled]="logto.isLoading()" (click)="loadAccessToken()">
        API-Zugangstoken abrufen
      </button>
      <pre>{{ accessToken() }}</pre>
    }
  `,
})
export class ApiResourceComponent {
  readonly logto = inject(LogtoService);
  readonly accessToken = signal('');

  async loadAccessToken() {
    this.accessToken.set(await this.logto.getAccessToken('https://shopping.your-app.com/api'));
  }
}

Diese Methode gibt ein JWT-Zugangstoken zurück, das verwendet werden kann, um auf die API-Ressource zuzugreifen, wenn der Benutzer die entsprechenden Berechtigungen hat. Wenn das aktuell zwischengespeicherte Zugangstoken abgelaufen ist, versucht diese Methode automatisch, ein Auffrischungstoken zu verwenden, um ein neues Zugangstoken zu erhalten.

Verwende den exakten Ressourcenbezeichner aus deiner Konfiguration. Rufe getAccessToken(resource) immer dann auf, wenn du eine API-Anfrage stellst, damit das SDK ein gültiges Token zurückgeben kann, anstatt ein Token unbegrenzt in deiner Komponente zu behalten.

Organisationstokens abrufen

Wenn Organisationen neu für dich sind, lies bitte 🏢 Organisationen (Multi-Tenancy), um loszulegen.

Du musst die Berechtigung UserScope.Organizations hinzufügen, wenn du den Logto-Client konfigurierst:

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto, UserScope } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: [UserScope.Organizations],
    }),
    // ...other providers
  ],
};

Sobald der Benutzer angemeldet ist, kannst du das Organisationstoken für den Benutzer abrufen:

app/organizations.component.ts
import { Component, effect, inject, signal } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-organizations',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    }
    @if (logto.isAuthenticated()) {
      <ul>
        @for (organizationId of organizationIds(); track organizationId) {
          <li>
            <span>{{ organizationId }}</span>
            <button
              type="button"
              [disabled]="logto.isLoading()"
              (click)="loadOrganizationToken(organizationId)"
            >
              Organisationstoken (Organization token) abrufen
            </button>
          </li>
        }
      </ul>
      <pre>{{ organizationToken() }}</pre>
    }
  `,
})
export class OrganizationsComponent {
  readonly logto = inject(LogtoService);
  readonly organizationIds = signal<string[]>([]);
  readonly organizationToken = signal('');

  constructor() {
    effect(() => {
      if (!this.logto.isAuthenticated()) {
        this.organizationIds.set([]);
        this.organizationToken.set('');
        return;
      }

      void this.logto
        .getIdTokenClaims()
        .then((claims) => {
          this.organizationIds.set(claims.organizations ?? []);
        })
        .catch(() => {
          // Das SDK gibt den Fehler über logto.error() für das Template aus.
        });
    });
  }

  async loadOrganizationToken(organizationId: string) {
    this.organizationToken.set(await this.logto.getOrganizationToken(organizationId));
  }
}

Füge UserScope.Organizations zu allen bestehenden Berechtigungen hinzu und melde dich nach der Aktualisierung der Konfiguration erneut an. getOrganizationToken(organizationId) gibt ein Token für die ausgewählte Logto-Organisation zurück; verwende getAccessToken(resource) für ein API-Ressourcen-Token.

Zugangstoken an Anfrage-Header anhängen

Platziere das Token im Authorization HTTP-Header im Bearer-Format (Bearer YOUR_TOKEN). Füge zum Beispiel diese Methode zu einer authentifizierten Komponente hinzu, die LogtoService injiziert:

async fetchProducts() {
  const accessToken = await this.logto.getAccessToken('https://shopping.your-app.com/api');
  const response = await fetch('https://shopping.your-app.com/api/products', {
    headers: {
      Authorization: `Bearer ${accessToken}`,
    },
  });

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }

  return response.json();
}

hinweis:

Das Beispiel verwendet fetch. Wenn du Angular HttpClient verwendest, setze denselben Authorization-Header in dessen Anfrageoptionen.

Weiterführende Lektüre

Endbenutzerflüsse: Authentifizierungsflüsse, Kontoflüsse und Organisationsflüsse Connectors konfigurieren Autorisierung (Authorization)

Voraussetzungen​

Installation​

Integration​

Logto-Provider initialisieren​

Redirect-URIs konfigurieren​

Bezüglich der umleitungsbasierten Anmeldung​

Redirect-URIs konfigurieren​

Redirect behandeln​

Anmeldung und Abmeldung implementieren​

Checkpoint: Teste deine Anwendung​

Benutzerinformationen abrufen​

Benutzerinformationen anzeigen​

Zusätzliche Ansprüche anfordern​

Ansprüche, die Netzwerk-Anfragen benötigen​

Berechtigungen und Ansprüche​

Standard OIDC-Berechtigungen (Scopes)​

Erweiterte Berechtigungen (Scopes)​

API-Ressourcen​

Logto-Client konfigurieren​

Zugangstoken für die API-Ressource abrufen​

Organisationstokens abrufen​

Zugangstoken an Anfrage-Header anhängen​

Weiterführende Lektüre​

Voraussetzungen

Installation

Integration

Logto-Provider initialisieren

Redirect-URIs konfigurieren

Bezüglich der umleitungsbasierten Anmeldung

Redirect-URIs konfigurieren

Redirect behandeln

Anmeldung und Abmeldung implementieren

Checkpoint: Teste deine Anwendung

Benutzerinformationen abrufen

Benutzerinformationen anzeigen

Zusätzliche Ansprüche anfordern

Ansprüche, die Netzwerk-Anfragen benötigen

Berechtigungen und Ansprüche

Standard OIDC-Berechtigungen (Scopes)

Erweiterte Berechtigungen (Scopes)

API-Ressourcen

Logto-Client konfigurieren

Zugangstoken für die API-Ressource abrufen

Organisationstokens abrufen

Zugangstoken an Anfrage-Header anhängen

Weiterführende Lektüre