Authentifizierung zu deiner Vue 3-Anwendung hinzufügen
Dieser Leitfaden zeigt dir, wie du Logto in deine Vue 3-Anwendung integrierst.
- Das Logto Vue SDK ist mit der Composition API gebaut und nutzt die Composables, daher ist es nur mit Vue 3 kompatibel.
- Das Tutorial-Video ist auf unserem YouTube-Kanal verfügbar.
- Das vollständige 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-Konsole erstellt wurde.
- Ein Vue 3-Projekt.
Installation
- npm
- pnpm
- yarn
npm i @logto/vue
pnpm add @logto/vue
yarn add @logto/vue
Integration
LogtoClient initialisieren
Importiere und verwende createLogto
, um das Logto-Plugin zu installieren:
import { createLogto, LogtoConfig } from '@logto/vue';
import { createApp } from 'vue';
import App from './App.vue';
const config: LogtoConfig = {
endpoint: '<your-logto-endpoint>',
appId: '<your-application-id>',
};
const app = createApp(App);
app.use(createLogto, config);
app.mount('#app');
Konfigurieren von Redirect-URIs
Bevor wir in die Details eintauchen, hier ein kurzer Überblick über die Endbenutzererfahrung. Der Anmeldeprozess kann wie folgt vereinfacht werden:
- Deine App ruft die Anmeldemethode auf.
- Der Benutzer wird zur 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 die Redirect-URI).
Bezüglich der umleitungsbasierten Anmeldung
- 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.
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.
Umgang mit Redirect
Es gibt noch Dinge zu tun, nachdem der Benutzer von Logto zurück zu deiner Anwendung umgeleitet wurde. Lass uns das richtig handhaben.
Zuerst erstellen wir eine Callback-Seite:
import { useHandleSignInCallback } from '@logto/vue';
import router from '@/router';
const { isLoading } = useHandleSignInCallback(() => {
// Etwas tun, wenn fertig, z.B. zur Startseite umleiten
});
<template>
<!-- Wenn es in Bearbeitung ist -->
<p v-if="isLoading">Weiterleiten...</p>
</template>
Füge den folgenden Code in deine /callback
-Route ein, die KEINE Authentifizierung erfordert:
// Angenommen vue-router
const router = createRouter({
routes: [
{
path: '/callback',
name: 'callback',
component: CallbackView,
},
],
});
Implementierung von Anmeldung und Abmeldung
Wir bieten zwei Composables useHandleSignInCallback()
und useLogto()
, die dir helfen können, den Authentifizierungsablauf einfach zu verwalten.
Bevor du .signIn()
aufrufst, stelle sicher, dass du die Redirect-URI im Admin Console korrekt konfiguriert hast.
import { useLogto } from '@logto/vue';
const { signIn, signOut, isAuthenticated } = useLogto();
const onClickSignIn = () => signIn('http://localhost:3000/callback');
const onClickSignOut = () => signOut('http://localhost:3000');
<template>
<button v-if="!isAuthenticated" @click="onClickSignIn">Anmelden</button>
<button v-else @click="onClickSignOut">Abmelden</button>
</template>
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 lokalen Speicher zu leeren und dich abzumelden.
Benutzerinformationen abrufen
Benutzerinformationen anzeigen
Um die Informationen des Benutzers anzuzeigen, kannst du die Methode getIdTokenClaims()
verwenden. Zum Beispiel auf deiner Startseite:
import { useLogto, type IdTokenClaims } from '@logto/vue';
import { ref } from 'vue';
const { isAuthenticated, getIdTokenClaims } = useLogto();
const user = ref<IdTokenClaims>();
if (isAuthenticated.value) {
(async () => {
const claims = await getIdTokenClaims();
user.value = claims;
})();
}
<template>
<div v-if="isAuthenticated && user">
<table class="table">
<thead>
<tr>
<th>Name</th>
<th>Wert</th>
</tr>
</thead>
<tbody>
<tr v-for="(value, key) in user" v-bind:key="key">
<td>{{ key }}</td>
<td>{{ typeof value === "string" ? value : JSON.stringify(value) }}</td>
</tr>
</tbody>
</table>
</div>
</template>
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.
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:
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
.
Um zusätzliche Berechtigungen anzufordern, kannst du die Logto-Provider-Konfigurationen anpassen:
import { createLogto, UserScope } from '@logto/vue';
const app = createApp(App);
app.use(createLogto, {
// ...andere Konfigurationen
scopes: [
UserScope.Email,
UserScope.Phone,
UserScope.CustomData,
UserScope.Identities,
UserScope.Organizations,
],
});
app.use(router);
Dann kannst du auf die zusätzlichen Ansprüche im Rückgabewert von getIdTokenClaims()
zugreifen:
const claims = await getIdTokenClaims();
// Jetzt kannst du auf zusätzliche Ansprüche wie `claims.email`, `claims.phone` usw. zugreifen.
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:
const { fetchUserInfo } = useLogto();
const userInfo = await fetchUserInfo();
// Jetzt kannst du auf den Anspruch `userInfo.custom_data` zugreifen
Berechtigungen und Ansprüche
Logto verwendet OIDC Berechtigungen und Ansprüche Konventionen, um die Berechtigungen und Ansprüche für das Abrufen von Benutzerinformationen aus dem ID-Token und dem OIDC userinfo endpoint zu definieren. Sowohl "Berechtigung (Scope)" als auch "Anspruch (Claim)" sind Begriffe aus den OAuth 2.0 und OpenID Connect (OIDC) Spezifikationen.
Hier ist die Liste der unterstützten Berechtigungen (Scopes) und der entsprechenden Ansprüche (Claims):
openid
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
sub | string | Der eindeutige Identifikator des Benutzers | Nein |
profile
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
name | string | Der vollständige Name des Benutzers | Nein |
username | string | Der Benutzername des Benutzers | Nein |
picture | string | URL des Profilbildes des Endbenutzers. Diese URL MUSS auf eine Bilddatei (zum Beispiel eine PNG-, JPEG- oder GIF-Bilddatei) verweisen und nicht auf eine Webseite, die ein Bild enthält. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das geeignet ist, den Endbenutzer zu beschreiben, und nicht auf ein beliebiges Foto, das vom Endbenutzer aufgenommen wurde. | Nein |
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. | Nein |
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. | Nein |
Andere Standardansprüche 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 angefordert werden muss. Ein Unterschied im Vergleich zu den oben genannten Ansprüchen besteht darin, dass diese Ansprüche nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die oben genannten Ansprüche null
zurückgeben, wenn die Werte leer sind.
Im Gegensatz zu den Standardansprüchen verwenden die Ansprüche created_at
und updated_at
Millisekunden anstelle von Sekunden.
email
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
string | Die E-Mail-Adresse des Benutzers | Nein | |
email_verified | boolean | Ob die E-Mail-Adresse verifiziert wurde | Nein |
phone
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
phone_number | string | Die Telefonnummer des Benutzers | Nein |
phone_number_verified | boolean | Ob die Telefonnummer verifiziert wurde | Nein |
address
Bitte siehe OpenID Connect Core 1.0 für die Details des Adressanspruchs.
custom_data
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
custom_data | object | Die benutzerdefinierten Daten des Benutzers | Ja |
identities
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
identities | object | Die verknüpften Identitäten des Benutzers | Ja |
sso_identities | array | Die verknüpften SSO-Identitäten des Benutzers | Ja |
urn:logto:scope:organizations
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
organizations | string[] | Die Organisations-IDs, denen der Benutzer angehört | Nein |
organization_data | object[] | Die Organisationsdaten, denen der Benutzer angehört | Ja |
urn:logto:scope:organization_roles
Anspruchsname | Typ | Beschreibung | Benötigt userinfo? |
---|---|---|---|
organization_roles | string[] | Die Organisationsrollen, denen der Benutzer angehört, im Format <organization_id>:<role_name> | Nein |
In Anbetracht der Leistung und der Datengröße bedeutet "Benötigt userinfo?" "Ja", dass der Anspruch nicht im ID-Token angezeigt wird, sondern in der Antwort des userinfo-Endpunkts zurückgegeben wird.
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:
import { createLogto } from '@logto/vue';
app.use(createLogto, {
// ...other configs
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});
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:
import { createLogto } from '@logto/vue';
app.use(createLogto, {
// ...other configs
scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});
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:
import { createLogto } from '@logto/vue';
app.use(createLogto, {
// ...other configs
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});
Für jede API-Ressource wird sowohl read
als auch write
Berechtigungen angefordert.
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.
Zugangstoken für die API-Ressource abrufen
Um das Zugangstoken für eine spezifische API-Ressource abzurufen, kannst du die Methode getAccessToken
verwenden:
import { useLogto, type UserInfoResponse } from '@logto/vue';
const { isAuthenticated, getAccessToken } = useLogto();
if (isAuthenticated.value) {
(async () => {
const accessToken = await getAccessToken('https://shopping.your-app.com/api');
console.log(accessToken);
})();
}
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.
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:
import { createLogto, UserScope } from '@logto/vue';
app.use(createLogto, {
// ...other configs
scopes: [UserScope.Organizations],
});
Sobald der Benutzer angemeldet ist, kannst du das Organisationstoken für den Benutzer abrufen:
import { useLogto } from '@logto/vue';
import { onMounted, ref } from 'vue';
const { getOrganizationToken, getOrganizationTokenClaims, getIdTokenClaims } = useLogto();
const organizationIds = ref<string[]>();
onMounted(async () => {
const claims = await getIdTokenClaims();
console.log('ID token claims', claims);
organizationIds.value = claims?.organizations;
});
const onClickFetchOrganizationToken = async (organizationId: string) => {
console.log('raw token', await getOrganizationToken(organizationId));
console.log('claims', await getOrganizationTokenClaims(organizationId));
};
<template>
<ul>
<li v-for="organizationId of organizationIds" v-bind:key="organizationId">
<span>{{ organizationId }}</span>
<button type="button" @click="onClickFetchOrganizationToken(organizationId)">
Token abrufen (siehe Konsole)
</button>
</li>
</ul>
</template>
Zugangstoken an Anfrage-Header anhängen
Platziere das Token im Authorization
-Feld der HTTP-Header im Bearer-Format (Bearer YOUR_TOKEN
), und du bist startklar.
Der Integrationsablauf des Bearer-Tokens kann je nach verwendetem Framework oder Anfrager variieren. Wähle deinen eigenen Weg, um den Anforderungs-Authorization
-Header anzuwenden.