Übungsaufgaben zur Anmeldung mit Keycloak in Vue: Mitfahrgesuche mit Token

Übungsaufgaben zur Anmeldung mit Keycloak in Vue: Mitfahrgesuche mit Token

https://bildung.social/@oerinformatik/

https://oer-informatik.de/vue-keycloak-oidc-uebungsaufgaben

Vue 3, Keycloak, OpenID Connect, OAuth 2.0, PKCE, Access Token, Navigation Guard, oidc-client-ts, Vitest, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 53 min, mehrere Aufgaben): Die Mitfahrgesuche in der Web-App des Mitfahrlabors sollen nur für angemeldete Personen erreichbar sein. In diesen Übungen bringst Du die Schritte des Authorization Code Flows mit PKCE in die richtige Reihenfolge und ordnest Tokens ihren Empfängern zu. Danach schützt Du die Seite „Meine Gesuche“ mit dem Navigation Guard und schickst ein neues Gesuch mit Access Token an die API, jeweils mit Tests. Zum Schluss findest Du anhand von Fehlermeldungen heraus, was bei der Anmeldung eines anderen Paars schiefläuft, und nimmst Stellung zu zwei Vorschlägen für mehr Bequemlichkeit [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über die Web-App mit Vue 3 und TypeScript: Projektübersicht / XP-Projektstart / TypeScript für Java-Entwickler*innen / Komponenten testgetrieben / API-Client aus OpenAPI / Router und Continuous Integration / Formulare und Validierung / Refactoring mit Pinia / Anmeldung mit Keycloak / Fahrer-Sicht und Coding Standards / Build und Auslieferung / End-to-End-Tests mit Playwright / Change Request Live-Aktualisierung

Diese Übungsaufgaben gehören zum Artikel Anmeldung mit Keycloak in Vue: Authorization Code mit PKCE. Alle Aufgaben spielen im Projektteam der Mitfahr-App Mitfahrlabor. Ausgangspunkt für die Aufgaben 2.1 und 2.2 ist das Projekt mitfahrlabor-web im Ordner src/08-vue-keycloak-oidc des Repositorys dieser Reihe mit dem Store useSitzungStore, dem Navigation Guard und der Anmelde-Attrappe src/mocks/anmeldung.ts. Was für die Gesuche fehlt, steht vollständig in den Aufgaben; die Lösungen der Übungen zu den vorigen Artikeln brauchst Du nicht.

Für die Gesuche nimmt das Team einen Endpunkt an, den das Backend in einer späteren Version bekommen soll: POST /v1/gesuche legt ein Gesuch für die angemeldete Person an (Rolle NUTZER), antwortet mit 201 und dem Gesuch samt id und mitfahrerId, ohne Token mit 401.

Hinweise zur Bearbeitung: Bis zur Teil-1-Prüfung der IT-Berufe solltest Du die Basiskompetenz beherrschen, also Aufgabe 1.1. Als FIA, FIDP oder FIDV musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das sind Aufgabe 2.1 und Aufgabe 2.2. Von FIA wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1) keine Probleme bereiten. Die Operatoren (ordnen, zuordnen, vorhersagen, entwickeln, analysieren, Stellung nehmen …) zeigen, wie ausführlich Du antworten sollst. Code schreibst Du in TypeScript bzw. als Single-File-Component von Vue 3 und prüfst ihn mit npm test, npm run type-check und npm run lint. Schreib Deine Lösung zuerst vollständig auf, bevor Du sie mit der Beispiellösung vergleichst.

Du möchtest eigene Aufgaben zum Üben von einem KI-Sprachmodell generieren lassen? Prompt ein-/ausblenden

Erstelle neue Übungsaufgaben zum Thema „Anmeldung mit Keycloak in Vue:
Mitfahrgesuche mit Token“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/vue-keycloak-oidc
- https://oer-informatik.de/szenario-mitfahrlabor
- https://oer-informatik.de/flurmonitor-change-request-keycloak
- Stilbeispiel: https://oer-informatik.de/vue-keycloak-oidc-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Vue 3
- Keycloak
- OpenID Connect
- OAuth 2.0
- PKCE
- Access Token
- Navigation Guard
- oidc-client-ts
- Vitest

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Aufgabe 1.1: Wer schickt was an wen? (Basiskompetenz)

(ca. 12 min Bearbeitungszeit)

Ben (Pseudonym Funkenflug) öffnet zum ersten Mal an diesem Tag die Adresse http://localhost:5173/gesuche. Die App ist wie im Artikel gebaut.

a) Bring die folgenden Schritte in die Reihenfolge, in der sie ablaufen. (6 Punkte)

b) Ordne jedem Token zu, wer es auswertet und wozu. (3 Punkte)

c) Ein Mitschüler schlägt vor, der Web-App ein Client Secret zu geben, „damit nicht jeder Codes eintauschen kann“. Erkläre, warum das nicht hilft und was stattdessen dafür sorgt. (2 Punkte)

d) Sag voraus, was passiert, wenn Ben nach der Anmeldung den Button „Abmelden“ klickt und danach im selben Tab wieder /gesuche aufruft. Nenne zwei Dinge, die nacheinander geschehen. (2 Punkte)

Aufgabe 2.1: „Meine Gesuche“ nur mit Anmeldung (Kernkompetenz)

(ca. 11 min Bearbeitungszeit)

Die App bekommt zwei neue Seiten: src/views/GesucheSeite.vue für die eigenen Gesuche und src/views/HilfeSeite.vue mit einer kurzen Erklärung, die auch ohne Konto lesbar sein soll. Für die Aufgabe genügen diese Platzhalter:

<!-- src/views/GesucheSeite.vue -->
<template>
  <section>
    <h2>Meine Gesuche</h2>
  </section>
</template>

<!-- src/views/HilfeSeite.vue -->
<template>
  <section>
    <h2>So funktioniert das Mitfahrlabor</h2>
    <p>Fahrten suchen, Platz anfragen, mitfahren. Zum Anmelden brauchst Du Dein Schulkonto.</p>
  </section>
</template>

a) Ergänze in src/router/index.ts die Routen /gesuche (Name gesuche) und /so-gehts (Name hilfe). Nur angemeldete Personen dürfen die Gesuche sehen, die Hilfe ist öffentlich. Beide Seiten sollen erst bei Bedarf geladen werden. (4 Punkte)

  // vor der Route „nicht gefunden“ in routes:
  { path: '/gesuche', name: 'gesuche', component: () => import('@/views/GesucheSeite.vue') },
  {
    path: '/so-gehts',
    name: 'hilfe',
    component: () => import('@/views/HilfeSeite.vue'),
    meta: { oeffentlich: true },
  },

b) Entwickle in src/__tests__/gesucheRoute.spec.ts drei Tests mit angemeldetesPinia() aus src/mocks/anmeldung.ts: Ohne Anmeldung führt /gesuche zur Anmeldung mit dem richtigen Ziel und nicht zur Seite. Ohne Anmeldung zeigt /so-gehts die Hilfe, ohne dass eine Anmeldung startet. Mit Kaffeetasse zeigt /gesuche die Überschrift „Meine Gesuche“. (6 Punkte)

import { describe, it, expect } from 'vitest'
import { mount } from '@vue/test-utils'
import { createMemoryHistory } from 'vue-router'
import App from '@/App.vue'
import { erzeugeRouter } from '@/router'
import { angemeldetesPinia } from '@/mocks/anmeldung'

describe('Routen für Gesuche und Hilfe', () => {
  it('schickt ohne Anmeldung von /gesuche zu Keycloak und merkt sich das Ziel', async () => {
    const { attrappe } = angemeldetesPinia(null)
    const router = erzeugeRouter(createMemoryHistory())
    await router.push('/gesuche')
    expect(attrappe.gestartetMitZiel).toEqual(['/gesuche'])
    expect(router.currentRoute.value.name).not.toBe('gesuche')
  })

  it('zeigt /so-gehts ohne Anmeldung und ohne Weiterleitung', async () => {
    const { pinia, attrappe } = angemeldetesPinia(null)
    const router = erzeugeRouter(createMemoryHistory())
    await router.push('/so-gehts')
    const wrapper = mount(App, { global: { plugins: [pinia, router] } })
    expect(attrappe.gestartetMitZiel).toEqual([])
    expect(wrapper.get('h2').text()).toBe('So funktioniert das Mitfahrlabor')
  })

  it('zeigt /gesuche, wenn Kaffeetasse angemeldet ist', async () => {
    const { pinia } = angemeldetesPinia()
    const router = erzeugeRouter(createMemoryHistory())
    await router.push('/gesuche')
    const wrapper = mount(App, { global: { plugins: [pinia, router] } })
    expect(router.currentRoute.value.name).toBe('gesuche')
    expect(wrapper.get('h2').text()).toBe('Meine Gesuche')
  })
})

c) Begründe, warum das Team den Guard so gebaut hat, dass jede neue Route ohne weiteres Zutun geschützt ist. (2 Punkte)

Aufgabe 2.2: Ein Gesuch mit Token aufgeben (Kernkompetenz)

(ca. 13 min Bearbeitungszeit)

Für POST /v1/gesuche gibt es noch keine Operation im erzeugten Client. Bis der Vertrag sie enthält, schreibt das Paar eine eigene Funktion mit fetch. Vorgegeben ist der Typ in src/domain/gesuchaufgeben.ts:

import type { Richtung } from './typen'

/** neues Mitfahrgesuch, wie es POST /v1/gesuche erwartet */
export interface GesuchNeu {
  haltepunktId: number
  richtung: Richtung
  datum: string // JJJJ-MM-TT
  zeitVon: string // HH:MM
  zeitBis: string // HH:MM
}

export type GesuchErgebnis =
  | { art: 'angelegt'; id: number }
  | { art: 'nicht-angemeldet' }
  | { art: 'abgelehnt'; status: number }

Beispiel für einen Test: Kaffeetasse (ID 3) sucht für Donnerstag, den 26.11.2026, ab Halle (Haltepunkt 3) eine Fahrt zur Schule zwischen 07:00 und 07:30 Uhr.

a) Entwickle die Funktion gibGesuchAuf(neu: GesuchNeu, holeToken: () => string | undefined, basis = '/v1'): Promise<GesuchErgebnis>. Sie schickt das Gesuch mit dem aktuellen Access Token, wertet 201, 401 und alle anderen Statuscodes aus und schickt ohne Token gar keine Anfrage. (6 Punkte)

export async function gibGesuchAuf(
  neu: GesuchNeu,
  holeToken: () => string | undefined,
  basis = '/v1',
): Promise<GesuchErgebnis> {
  const token = holeToken()
  if (token === undefined) {
    return { art: 'nicht-angemeldet' }
  }
  const antwort = await fetch(`${basis}/gesuche`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${token}` },
    body: JSON.stringify(neu),
  })
  if (antwort.status === 201) {
    const gesuch = (await antwort.json()) as { id: number }
    return { art: 'angelegt', id: gesuch.id }
  }
  if (antwort.status === 401) {
    return { art: 'nicht-angemeldet' }
  }
  return { art: 'abgelehnt', status: antwort.status }
}

b) Entwickle drei Tests mit MSW: Header und Body der Anfrage für das Beispielgesuch, Antwort 401 und ein Aufruf ohne Token, Antwort 422. (6 Punkte)

import { describe, it, expect } from 'vitest'
import { http, HttpResponse } from 'msw'
import { gibGesuchAuf, type GesuchNeu } from '@/domain/gesuchaufgeben'
import { API } from '@/mocks/handlers'
import { server } from '@/mocks/server'
import { testToken } from '@/mocks/anmeldung'

const gesuch: GesuchNeu = { haltepunktId: 3, richtung: 'zur-schule', datum: '2026-11-26', zeitVon: '07:00', zeitBis: '07:30' }

describe('gibGesuchAuf', () => {
  it('schickt das Token im Header und keine mitfahrerId im Body', async () => {
    let kopf: string | null = null
    let body: Record<string, unknown> = {}
    server.use(
      http.post(`${API}/gesuche`, async ({ request }) => {
        kopf = request.headers.get('Authorization')
        body = (await request.json()) as Record<string, unknown>
        return HttpResponse.json({ ...body, id: 6, mitfahrerId: 3, status: 'offen' }, { status: 201 })
      }),
    )
    expect(await gibGesuchAuf(gesuch, () => testToken(3), API)).toEqual({ art: 'angelegt', id: 6 })
    expect(kopf).toBe('Bearer test-token-3')
    expect(body).not.toHaveProperty('mitfahrerId')
  })

  it('meldet „nicht angemeldet“ bei 401 und schickt ohne Token gar nichts', async () => {
    let aufrufe = 0
    server.use(
      http.post(`${API}/gesuche`, () => {
        aufrufe++
        return new HttpResponse(null, { status: 401 })
      }),
    )
    expect(await gibGesuchAuf(gesuch, () => 'abgelaufen', API)).toEqual({ art: 'nicht-angemeldet' })
    expect(await gibGesuchAuf(gesuch, () => undefined, API)).toEqual({ art: 'nicht-angemeldet' })
    expect(aufrufe).toBe(1)
  })

  it('meldet andere Ablehnungen mit Status', async () => {
    server.use(http.post(`${API}/gesuche`, () => new HttpResponse(null, { status: 422 })))
    expect(await gibGesuchAuf(gesuch, () => testToken(3), API)).toEqual({ art: 'abgelehnt', status: 422 })
  })
})

c) Erläutere, warum GesuchNeu keine mitfahrerId enthält, obwohl das Backend sie im Ergebnis zurückgibt. (2 Punkte)

Aufgabe 3.1: Anmeldung mit Hindernissen (Profilkompetenz)

(ca. 17 min Bearbeitungszeit)

Ein zweites Paar im Team des Projekts Mitfahrlabor hat die Anmeldung für die Gesuche in einem eigenen Zweig gebaut, mit oidc-client-ts und demselben Realm. Beim Ausprobieren notiert es vier Beobachtungen. Ausschnitte aus seinem Code:

// src/auth/oidcAnmeldedienst.ts (Ausschnitt)
const manager = new UserManager({
  authority: 'http://localhost:8180/realms/mitfahrlabor',
  client_id: 'mitfahrlabor-web',
  redirect_uri: 'http://localhost:5173/anmeldung/rueckkehr',
  response_type: 'code',
  scope: 'openid',
  automaticSilentRenew: true,
})

// src/main.ts (Ausschnitt)
await sitzung.pruefe()
client.setConfig({ baseUrl: '/v1', auth: sitzung.accessToken })

• Beobachtung A: Ein zweiter Entwicklungsserver lief noch. Vite startet deshalb auf Port 5174. Ruft Lina (Pseudonym Rotkehlchen) http://localhost:5174/gesuche auf, zeigt Keycloak statt der Anmeldeseite: „Invalid parameter: redirect_uri“.

• Beobachtung B: Jonas ruft die App über http://127.0.0.1:5173/ auf. Er kommt zur Anmeldeseite und meldet sich an. Danach steht dort „Die Anmeldung hat nicht geklappt.“, die Konsole zeigt No matching state found in storage.

• Beobachtung C: Nach der Anmeldung funktioniert alles. Nach gut fünf Minuten erscheint bei jeder Liste „Die Gesuche können gerade nicht geladen werden.“, obwohl oben noch „Angemeldet als Kaffeetasse“ steht. Im Netzwerk-Reiter: Antwort 401 mit WWW-Authenticate: Bearer error="invalid_token", error_description="… Jwt expired …". Im sessionStorage steht ein neueres Access Token als im Header der Anfrage.

• Beobachtung D: Das Paar hat in Keycloak ein Testkonto probe mit Attribut pseudonym = „Probe“ angelegt. Die Anmeldung gelingt, aber POST /v1/angebote/1/buchungen antwortet mit 403 und „Kein Konto im Mitfahrlabor für Probe“.

a) Analysiere die vier Beobachtungen: Nenne jeweils die Ursache und eine passende Behebung. (12 Punkte)

b) Für mehr Bequemlichkeit schlägt das Paar zwei Änderungen vor: Die Tokens sollen im localStorage liegen, damit man nach einem Neustart des Browsers angemeldet bleibt. Und das Access Token soll in Keycloak 8 Stunden gelten, „dann gibt es keine Probleme mit dem Ablauf mehr“. Nimm zu beiden Vorschlägen Stellung und nenne für den Wunsch nach weniger Anmeldungen eine bessere Lösung. (6 Punkte)

Links und weitere Informationen

• Anmeldung mit Keycloak in Vue: Authorization Code mit PKCE, der Artikel zu diesen Übungen

• Change Request: Keycloak und Projekt-Retro mit dem Backend als Resource Server

• oidc-client-ts und Vue Router: Navigation Guards

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zur Anmeldung mit Keycloak in Vue: Mitfahrgesuche mit Token” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/vue-keycloak-oidc-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/programmierung/vue. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]