{"id":6952,"date":"2026-08-24T16:33:27","date_gmt":"2026-08-24T16:33:27","guid":{"rendered":"https:\/\/technodidact.de\/?p=6952"},"modified":"2026-08-24T16:33:27","modified_gmt":"2026-08-24T16:33:27","slug":"die-evolution-der-api-authentifizierung-von-passwoertern-zu-vertrauenslosen-systemen","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/die-evolution-der-api-authentifizierung-von-passwoertern-zu-vertrauenslosen-systemen\/","title":{"rendered":"Die Evolution der API-Authentifizierung: Von Passw\u00f6rtern zu vertrauenslosen Systemen"},"content":{"rendered":"

Autor: DerSchneider<\/strong><\/p>\n\n\n\n

\n\n\n\n

Einleitung<\/h2>\n\n\n\n

In der digitalen Welt ist der Zugang zu Daten und Funktionen das h\u00f6chste Gut. Ob eine Wetter-App Daten von einem Server abruft, ein Zahlungsdienstleister eine Transaktion autorisiert oder ein Smart-Home-System mit der Cloud kommuniziert \u2013 all diese Vorg\u00e4nge basieren auf Application Programming Interfaces (APIs). Doch wie stellt ein System sicher, dass derjenige, der eine Anfrage stellt, auch tats\u00e4chlich der ist, f\u00fcr den er sich ausgibt? Die Antwort auf diese Frage ist die API-Authentifizierung.<\/p>\n\n\n\n

F\u00fcr viele Entwickler ist das Thema ein Begriffsdschungel. API-Key, JWT, OAuth, Bearer-Token \u2013 die Begriffe werden oft synonym verwendet, obwohl sie grundlegend unterschiedliche Konzepte beschreiben. Einige sind simple \u00dcbertragungsformate, andere komplexe Protokoll-Frameworks. Diese Vielfalt ist das Ergebnis einer jahrzehntelangen Evolution, die von der schlichten \u00dcbertragung von Benutzernamen und Passw\u00f6rtern bis hin zu hochkomplexen, zertifikatsbasierten Vertrauensmodellen reicht.<\/p>\n\n\n\n

Dieser Artikel beleuchtet die historische Entwicklung der API-Authentifizierung, erkl\u00e4rt die Funktionsweise der g\u00e4ngigsten Methoden und bietet einen Entscheidungsrahmen f\u00fcr die Wahl der richtigen Strategie.<\/p>\n\n\n\n

\n\n\n\n

Die \u00c4ra der simplen Credentials: Basic und Digest Authentication<\/h2>\n\n\n\n

Die Anf\u00e4nge der Web-Authentifizierung waren von Einfachheit gepr\u00e4gt. Mit der Basic Authentication<\/strong> wurde der Grundstein f\u00fcr die Identifikation im HTTP-Protokoll gelegt. Die Funktionsweise ist denkbar simpel: Der Client sendet einen Benutzernamen und ein Passwort im Authorization<\/code>-Header der HTTP-Anfrage. Die Credentials werden lediglich mit Base64 kodiert \u2013 ein Verfahren, das keine Verschl\u00fcsselung, sondern lediglich eine Kodierung darstellt <\/a>. Ohne die Nutzung von HTTPS kann jede Person, die den Netzwerkverkehr abh\u00f6rt, die Anmeldeinformationen im Klartext lesen. Dies machte Basic Authentication von Anfang an anf\u00e4llig und f\u00fchrte dazu, dass sie heute in Produktivumgebungen kaum noch anzutreffen ist, es sei denn, sie wird strikt mit TLS-Verschl\u00fcsselung kombiniert <\/a><\/a>.<\/p>\n\n\n\n

Als Reaktion auf die offensichtlichen Schw\u00e4chen der Basic Authentication wurde die Digest Authentication<\/strong> entwickelt. Sie verbesserte die Sicherheit durch ein sogenanntes Challenge-Response-Verfahren. Der Server sendet zun\u00e4chst eine zuf\u00e4llige Zeichenfolge (ein „Nonce“) an den Client. Der Client erstellt daraufhin einen Hash-Wert, der unter anderem das Passwort, den Benutzernamen und dieses Nonce kombiniert, und sendet diesen Hash zur\u00fcck <\/a><\/a>. Der Server kann anhand seines eigenen Wissens \u00fcber das Passwort denselben Hash berechnen und so den Client authentifizieren, ohne das Passwort selbst \u00fcber das Netzwerk senden zu m\u00fcssen <\/a>. Obwohl dieser Mechanismus deutlich sicherer ist, konnte sich Digest Authentication aufgrund seiner h\u00f6heren Komplexit\u00e4t und der sp\u00e4ter aufkommenden, flexibleren Token-basierten Verfahren nicht als Standard durchsetzen <\/a><\/a>.<\/p>\n\n\n\n

Merkmal<\/th>Basic Authentication<\/th>Digest Authentication<\/th><\/tr><\/thead>
Sicherheit<\/strong><\/td>Gering (Base64-Kodierung, kein Hash)<\/td>Mittel (Hash-basiertes Challenge-Response)<\/td><\/tr>
Passwort\u00fcbertragung<\/strong><\/td>Im Klartext (Base64)<\/td>Wird niemals \u00fcbertragen<\/td><\/tr>
Schutz vor Man-in-the-Middle<\/strong><\/td>Nur mit HTTPS<\/td>Besser, aber dennoch anf\u00e4llig ohne HTTPS<\/td><\/tr>
Komplexit\u00e4t<\/strong><\/td>Sehr gering<\/td>Gering bis mittel<\/td><\/tr>
Einsatz heute<\/strong><\/td>Fast ausschlie\u00dflich mit HTTPS f\u00fcr einfache Systeme<\/td>Selten, meist in Legacy-Systemen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

Sitzungsbasierte Verwaltung: Die Geburt von Cookies und Sessions<\/h2>\n\n\n\n

Mit dem Aufkommen dynamischer Webanwendungen und der Notwendigkeit, den Anmeldestatus eines Benutzers \u00fcber mehrere Seitenaufrufe hinweg zu erhalten, wurde eine neue L\u00f6sung erforderlich. Die Session-Authentifizierung<\/strong> l\u00f6ste dieses Problem, indem sie den Zustand (den „Login-Status“) auf dem Server speicherte <\/a>.<\/p>\n\n\n\n

Der Ablauf ist aus modernen Webanwendungen bekannt: Der Benutzer gibt seine Anmeldedaten ein, der Server \u00fcberpr\u00fcft diese und erstellt daraufhin eine Sitzung (Session) f\u00fcr den Benutzer. Eine eindeutige Sitzungs-ID (Session-ID) wird daraufhin an den Browser des Clients gesendet \u2013 typischerweise in Form eines Cookies. Bei jeder weiteren Anfrage sendet der Browser dieses Cookie automatisch mit, und der Server kann anhand der Session-ID den Benutzer identifizieren, ohne dass die Anmeldeinformationen erneut gesendet werden m\u00fcssen <\/a>.<\/p>\n\n\n\n

Diese Architektur erwies sich f\u00fcr klassische serverseitig gerenderte Webanwendungen als \u00e4u\u00dferst effektiv. Sie brachte jedoch eine entscheidende Herausforderung mit sich: Zustandslosigkeit vs. Skalierbarkeit<\/strong>. Da der Server den Sitzungszustand speichert, m\u00fcssen alle Anfragen eines Benutzers an denselben Server (oder einen gemeinsam genutzten Sitzungsspeicher wie Redis) weitergeleitet werden. In modernen, horizontal skalierenden Microservices-Architekturen wird dies schnell zu einem Flaschenhals und einer Frage der Komplexit\u00e4t, da der Sitzungsspeicher zentral verwaltet und synchronisiert werden muss <\/a>.<\/p>\n\n\n\n

\n\n\n\n

Die Token-Revolution: API-Keys, Bearer-Tokens und JWT<\/h2>\n\n\n\n

Der Wunsch nach Zustandslosigkeit, Skalierbarkeit und einer einfacheren Handhabung in verteilten Systemen f\u00fchrte zur Abl\u00f6sung von Sessions durch Token-basierte Authentifizierung.<\/p>\n\n\n\n

API-Keys: Der einfache Identifikator<\/h3>\n\n\n\n

Der API-Key<\/strong> ist das einfachste Token-Konzept. Es handelt sich um einen eindeutigen, meist langen alphanumerischen String, der einer Anwendung oder einem Entwickler zugewiesen wird <\/a>. Der Client sendet diesen Key bei jedem API-Aufruf mit \u2013 oft im Header oder als Query-Parameter.<\/p>\n\n\n\n

API-Keys sind weit verbreitet f\u00fcr \u00f6ffentliche Dienste wie Wetter- oder Geodaten-APIs. Sie sind einfach zu implementieren und zu verwalten. Ihr entscheidender Nachteil ist jedoch, dass sie meist nur die Anwendung identifizieren, nicht aber den einzelnen Benutzer. Zudem bieten sie nur eine grobe Sicherheit, da ein kompromittierter Key unbegrenzt g\u00fcltig ist, solange er nicht manuell rotiert wird <\/a>.<\/p>\n\n\n\n

Bearer-Tokens: Der Inhaber ist der K\u00f6nig<\/h3>\n\n\n\n

Eine Weiterentwicklung ist das Bearer-Token<\/strong>. Im Gegensatz zum API-Key ist das Bearer-Token kein statischer String, sondern ein meist kurzlebiges, dynamisches Token. Es wird im Authorization: Bearer <token><\/code>-Header \u00fcbertragen <\/a>. Das Prinzip ist einfach: Wer den Token besitzt (der „Bearer“), darf ihn nutzen.<\/em> Der Server muss den Token lediglich auf G\u00fcltigkeit und Korrektheit pr\u00fcfen, ohne daf\u00fcr eine serverseitige Session zu ben\u00f6tigen.<\/p>\n\n\n\n

Diese Zustandslosigkeit ist der gro\u00dfe Vorteil von Bearer-Tokens, da der Server keine Daten speichern muss, was die Skalierung enorm vereinfacht <\/a>. Die Sicherheit liegt jedoch vollst\u00e4ndig in der sicheren Aufbewahrung und \u00dcbertragung des Tokens. Ein gestohlener Token kann f\u00fcr b\u00f6swillige Zwecke verwendet werden, bis er abl\u00e4uft <\/a>.<\/p>\n\n\n\n

JWT: Das strukturierte Token<\/h3>\n\n\n\n

Der JSON Web Token (JWT)<\/strong> ist kein Authentifizierungsprotokoll, sondern ein Token-Format<\/strong> <\/a>. Ein JWT besteht aus drei Teilen (Header, Payload, Signatur), die mit Base64url kodiert und durch Punkte getrennt sind. Die Signatur (z.B. mittels HS256 oder RS256) stellt sicher, dass das Token nicht manipuliert wurde <\/a><\/a>.<\/p>\n\n\n\n

Der entscheidende Vorteil eines JWT gegen\u00fcber einem einfachen Bearer-Token ist das strukturierte Payload<\/strong>. Das Token kann alle notwendigen Informationen \u00fcber den Benutzer oder die Sitzung (wie Benutzer-ID, Rollen, Ablaufzeit) enthalten. Der Server kann diese Informationen aus dem Token selbst lesen und muss keine Datenbankabfrage durchf\u00fchren <\/a>. Dies macht JWTs extrem attraktiv f\u00fcr Microservices und verteilte Systeme, da sie die Anzahl der notwendigen Datenbankzugriffe reduzieren und so die Performance steigern <\/a>.<\/p>\n\n\n\n

Allerdings sind JWTs nicht ohne T\u00fccken. Entwickler m\u00fcssen sicherstellen, dass sie den alg: none<\/code>-Angriff abwehren, bei dem ein Angreifer die Signatur ganz wegl\u00e4sst. Schwache gemeinsame Geheimnisse bei Verwendung von HS256 sind ebenso ein Risiko wie die unsichere Speicherung im localStorage<\/code> des Browsers, der f\u00fcr Cross-Site-Scripting (XSS)-Angriffe anf\u00e4llig ist <\/a>.<\/p>\n\n\n\n

\n\n\n\n

Autorisierungsprotokolle: OAuth 2.0, OIDC und SSO<\/h2>\n\n\n\n

Die bisherigen Methoden dienen in erster Linie der Authentifizierung und sind eher f\u00fcr den direkten Zugriff einer vertrauensw\u00fcrdigen Anwendung auf einen Server gedacht. In der modernen, vernetzten Welt ist jedoch ein Szenario allgegenw\u00e4rtig, das eine andere L\u00f6sung erfordert: Eine Anwendung m\u00f6chte im Namen eines Benutzers auf Ressourcen eines anderen Dienstes zugreifen \u2013 ohne dessen Passwort zu kennen.<\/p>\n\n\n\n

OAuth 2.0: Die Berechtigungsdelegation<\/h3>\n\n\n\n

OAuth 2.0<\/strong> ist kein Authentifizierungsprotokoll, sondern ein Autorisierungs-Framework<\/strong> <\/a><\/a>. Es erm\u00f6glicht einer Anwendung („Client“), f\u00fcr einen bestimmten Zweck und einen begrenzten Zeitraum Zugriff auf gesch\u00fctzte Ressourcen eines Benutzers zu erhalten, ohne dass der Client jemals das Passwort des Benutzers sehen oder speichern muss <\/a><\/a>.<\/p>\n\n\n\n

Der typische Ablauf (Authorization Code Grant) funktioniert so: Der Benutzer wird zum Authentifizierungsdienst („Authorization Server“) des Ressourcenbesitzers weitergeleitet. Dort meldet er sich an und erteilt der Anwendung die gew\u00fcnschte Berechtigung. Der Dienst gibt daraufhin einen Autorisierungscode an die Anwendung zur\u00fcck. Dieser Code wird dann serverseitig gegen ein Access-Token<\/strong> eingetauscht, welches dann f\u00fcr den Zugriff auf die eigentliche Ressource verwendet wird <\/a><\/a><\/a>.<\/p>\n\n\n\n

OAuth 2.0 Grant Type<\/th>Hauptverwendung<\/th>Sicherheitsmerkmal<\/th><\/tr><\/thead>
Authorization Code + PKCE<\/strong><\/td>Web- und Mobile-Apps im Namen eines Benutzers<\/td>Sehr sicher (Code wird gegen Token getauscht)<\/td><\/tr>
Client Credentials<\/strong><\/td>Server-zu-Server-Kommunikation (kein Benutzer)<\/td>Gut geeignet f\u00fcr maschinelle Zugriffe <\/a><\/td><\/tr>
Device Code<\/strong><\/td>Ger\u00e4te ohne Browser (z.B. Smart-TV)<\/td>Umst\u00e4ndlich, aber sicher f\u00fcr eingeschr\u00e4nkte Ger\u00e4te<\/td><\/tr>
Implicit<\/strong><\/td>Veraltet!<\/strong> (Legacy Single-Page-Apps)<\/td>Sicherheitsrisiko!<\/strong> Sollte nicht mehr verwendet werden <\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

OpenID Connect (OIDC): Authentifizierung trifft auf Autorisierung<\/h3>\n\n\n\n

OAuth 2.0 ist ein reines Autorisierungs-Framework. Es definiert, was<\/em> eine Anwendung darf, aber nicht, wer<\/em> der Benutzer ist. Um diese L\u00fccke zu schlie\u00dfen, wurde OpenID Connect (OIDC)<\/strong> entwickelt. OIDC baut auf OAuth 2.0 auf und f\u00fcgt eine standardisierte Authentifizierungsebene hinzu <\/a><\/a>.<\/p>\n\n\n\n

Das Kernst\u00fcck von OIDC ist der ID-Token<\/strong>, ein JWT, der standardisierte Informationen \u00fcber den authentifizierten Benutzer (wie dessen E-Mail-Adresse oder Name) enth\u00e4lt <\/a><\/a>. Wenn Sie sich heute mit „Mit Google anmelden“ oder „Mit Microsoft anmelden“ bei einer Webseite einloggen, nutzen Sie in der Regel OIDC.<\/p>\n\n\n\n

OIDC ist damit die erste Wahl f\u00fcr moderne Web- und Mobile-Anwendungen, die sowohl eine sichere Authentifizierung als auch eine granulare Autorisierung ben\u00f6tigen, ohne selbst die Anmeldeinformationen der Benutzer verwalten zu m\u00fcssen <\/a>.<\/p>\n\n\n\n

Single Sign-On (SSO): Die Benutzererfahrung<\/h3>\n\n\n\n

Single Sign-On (SSO)<\/strong> ist kein Protokoll, sondern ein Anwendungsfall<\/strong> <\/a>. SSO beschreibt die Benutzererfahrung, bei der sich ein Benutzer einmalig anmeldet und dadurch automatisch Zugang zu mehreren verschiedenen Anwendungen oder Diensten erh\u00e4lt. Im Unternehmenskontext bedeutet dies: Ein Mitarbeiter loggt sich einmal in sein Unternehmenskonto ein und kann dann auf E-Mail, interne Dashboards und CRM-Systeme zugreifen, ohne sich jedes Mal neu authentifizieren zu m\u00fcssen <\/a>.<\/p>\n\n\n\n

Technisch realisiert wird SSO meist durch Protokolle wie OIDC, SAML (ein \u00e4lteres, XML-basiertes Protokoll) oder Kerberos <\/a>. Die dahinterliegende Architektur ist ein zentraler Identit\u00e4tsanbieter (IdP), der die Authentifizierung einmal vornimmt und dann den anderen Diensten (den Service-Providern) gegen\u00fcber die Identit\u00e4t des Benutzers best\u00e4tigt.<\/p>\n\n\n\n

\n\n\n\n

Vergleich und Entscheidungsfindung<\/h2>\n\n\n\n

Die Wahl der „richtigen“ Authentifizierungsmethode h\u00e4ngt stark vom spezifischen Anwendungsfall ab. Die folgende Entscheidungsmatrix fasst die Kernaspekte zusammen:<\/p>\n\n\n\n

Anwendungsfall<\/th>Empfohlene Methode<\/th>Begr\u00fcndung<\/th><\/tr><\/thead>
Einfache, \u00f6ffentliche APIs f\u00fcr Entwickler (z.B. Wetter)<\/td>API-Key<\/strong><\/td>Einfach zu implementieren, identifiziert die Anwendung, geringer Overhead <\/a><\/td><\/tr>
Web-Anwendung mit zentralem Server (z.B. CMS)<\/td>Session Cookie<\/strong><\/td>Einfach zu handhaben, gut f\u00fcr serverseitige Zustandsverwaltung <\/a><\/td><\/tr>
Microservices\/SPAs, skalierbare Backends<\/td>Bearer Token (JWT)<\/strong><\/td>Zustandslos, keine zentrale Speicherung, aber XSS-Risiken beachten <\/a><\/td><\/tr>
Drittanbieter-Zugriff auf Benutzerdaten (z.B. Google Drive)<\/td>OAuth 2.0 (Authorization Code + PKCE)<\/strong><\/td>Standard f\u00fcr Delegation, kein Passwort-Sharing, granulare Berechtigungen <\/a><\/td><\/tr>
„Login mit Google\/Facebook“<\/td>OpenID Connect (OIDC)<\/strong><\/td>Standard f\u00fcr Authentifizierung + Identit\u00e4t, baut auf OAuth 2.0 auf <\/a><\/td><\/tr>
Unternehmens-SSO (z.B. Salesforce, Office 365)<\/td>OIDC \/ SAML<\/strong><\/td>Erm\u00f6glicht einmaliges Anmelden \u00fcber mehrere Systeme hinweg <\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

Fazit und Ausblick: Auf dem Weg zu Zero Trust<\/h2>\n\n\n\n

Die Entwicklung der API-Authentifizierung ist eine fortlaufende Reise vom simplen, unsicheren Passwort hin zu dynamischen, standardisierten Vertrauensmodellen. Jede Stufe dieser Entwicklung \u2013 von Basic Auth \u00fcber Sessions bis hin zu OAuth 2.0 und OIDC \u2013 adressierte die spezifischen Herausforderungen ihrer Zeit. Die Zukunft geh\u00f6rt jedoch noch ausgefeilteren Konzepten, die \u00fcber die blo\u00dfe Authentifizierung hinausgehen.<\/p>\n\n\n\n

In der \u00c4ra von Zero-Trust-Architekturen<\/strong> ist keinem Benutzer oder System mehr automatisch zu vertrauen, selbst nicht innerhalb des eigenen Netzwerks. Dies f\u00fchrt zu einer Renaissance von Methoden wie mTLS (gegenseitiges TLS)<\/strong> f\u00fcr die service-seitige Authentifizierung in internen Mesh-Netzwerken <\/a>. Moderne Plattformen kombinieren zunehmend verschiedene Methoden \u2013 etwa OAuth 2.0 am Edge und mTLS im Backend \u2013 um eine mehrschichtige Sicherheit („Defense in Depth“) zu gew\u00e4hrleisten <\/a>.<\/p>\n\n\n\n

F\u00fcr den Softwareentwickler bleibt die Aufgabe, ein fundiertes Verst\u00e4ndnis dieser unterschiedlichen Konzepte zu entwickeln. Nur wer die historischen Wurzeln und die technischen Unterschiede versteht, kann eine fundierte Entscheidung treffen und Systeme entwerfen, die sowohl sicher als auch zukunftsf\u00e4hig sind. Die Wahl der falschen Methode ist nicht nur ein technisches Problem, sondern kann zu erheblichen Sicherheitsl\u00fccken f\u00fchren, die nach dem OWASP API Security Top 10<\/strong> als zweitkritischstes API-Risiko gelten <\/a>.<\/p>\n\n\n\n

\n\n\n\n

Quellen<\/h2>\n\n\n\n
    \n
  1. Bachao.ai<\/a>:\u00a0„API Authentication: API Keys vs OAuth 2.0 vs JWT“, 2026.\u00a0<\/a><\/li>\n\n\n\n
  2. LoginRadius: „OAuth vs API Key vs mTLS: Which API Authentication Method Wins?“, 2026.\u00a0<\/a><\/li>\n\n\n\n
  3. JumpCloud: „Single Sign-On Protocol Overview“, 2025.\u00a0<\/a><\/li>\n\n\n\n
  4. Aliyun Developer: „12\u79cdAPI\u8ba4\u8bc1\u5168\u573a\u666f\u89e3\u6790\uff1a\u4eceBasic\u5230OAuth2.0“, 2025.\u00a0<\/a><\/li>\n\n\n\n
  5. Cochrane Documentation: „Cochrane Account Single Sign-on“, 2026.\u00a0<\/a><\/li>\n\n\n\n
  6. Chromium Open Source: „SPDY Server and Proxy Authentication“.\u00a0<\/a><\/li>\n\n\n\n
  7. Claromentis Developer: „Authentication“.\u00a0<\/a><\/li>\n\n\n\n
  8. Ncloud Documentation: „Ncloud Single Sign-On concepts“, 2026.\u00a0<\/a><\/li>\n\n\n\n
  9. ScienceDirect: „Authorization Header“.\u00a0<\/a><\/li>\n<\/ol>","protected":false},"excerpt":{"rendered":"

    Autor: DerSchneider Einleitung In der digitalen Welt ist der Zugang zu Daten und Funktionen das h\u00f6chste Gut. Ob eine Wetter-App Daten von einem Server abruft, ein Zahlungsdienstleister eine Transaktion autorisiert oder ein Smart-Home-System mit der Cloud kommuniziert \u2013 all diese Vorg\u00e4nge basieren auf Application Programming Interfaces (APIs). Doch wie stellt ein System sicher, dass derjenige, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41,17,18,37],"tags":[],"class_list":["post-6952","post","type-post","status-publish","format-standard","hentry","category-digitalkultur","category-im-herz","category-im-kopf-methoden-werkzeuge","category-wissenspeicher"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6952","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=6952"}],"version-history":[{"count":1,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6952\/revisions"}],"predecessor-version":[{"id":6953,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6952\/revisions\/6953"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=6952"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=6952"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=6952"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}