OAuth2 und JWT einfach erklärt: APIs sicher authentifizieren

Was sind OAuth2, Access Tokens und JWTs? Dieses Einsteiger-Tutorial erklärt die Rollen der Beteiligten, Bearer Tokens, Client Credentials, sichere Token-Prüfung und typische Fehler.

1. Authentifizierung und Autorisierung

Authentifizierung beantwortet die Frage, wer der Aufrufer ist. Autorisierung beantwortet, was er darf. Ein gültiges Token ist nicht automatisch eine Berechtigung für jede Funktion. Das Beispiel einer Leserolle und einer Bearbeiterrolle macht den Unterschied deutlich.

2. Was ist OAuth 2.0?

OAuth 2.0 ist ein Framework, mit dem ein Client begrenzten Zugang zu geschützten Ressourcen erhalten kann. Es definiert unter anderem Rollen wie Resource Owner, Client, Authorization Server und Resource Server. OAuth2 selbst ist nicht dasselbe wie das Anmelden eines Benutzers; OpenID Connect ergänzt dazu eine Identitätsschicht.

3. Was ist ein Access Token?

Ein Access Token wird vom Authorization Server ausgestellt und vom Client bei Anfragen an die API übergeben. Es ist an einen bestimmten Verwendungszweck beziehungsweise eine Ressource gebunden und zeitlich begrenzt. Der API-Server muss entscheiden, ob er das Token akzeptiert.

4. Was ist JWT?

JSON Web Token ist ein Tokenformat mit Header, Payload und Signatur. Nicht jedes OAuth-Access-Token muss ein JWT sein. Ein signiertes JWT ist normalerweise lesbar und nicht automatisch verschlüsselt. Deshalb gehören vertrauliche Informationen nicht unüberlegt in Claims.

5. Der Ablauf bei einer Dienst-zu-Dienst-Integration

Eine C#-Anwendung kann mit Client Credentials ein Zugriffstoken für eine API erhalten. Sie authentifiziert sich am Token-Endpunkt, erhält ein Access Token und sendet es im Authorization-Header an den Resource Server. Die API validiert Signatur, Issuer, Audience, Ablaufzeit und erforderliche App-Rollen. Eine Client-Anwendung darf nie ihren geheimen Schlüssel an die aufgerufene Business-API weiterreichen.

6. Wie sieht eine API-Anfrage aus?

Der Authorization-Header enthält das Bearer Token. Dieses Beispiel zeigt nur den HTTP-Vertrag, kein echtes Token. Wer ein solches Token erhält, kann es je nach Berechtigung und Gültigkeit missbrauchen – deshalb darfst du es nicht öffentlich teilen.

GET /api/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json

7. Wie prüft ASP.NET Core ein Token?

Für Microsoft Entra ID lässt sich Microsoft.Identity.Web zur JWT-Bearer-Validierung verwenden. Die Konfiguration enthält TenantId und ClientId der geschützten API. Die eigentliche Berechtigungsprüfung erfolgt beispielsweise über eine Policy mit RequireRole. Rollen sollten immer serverseitig durchgesetzt werden.

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.Identity.Web;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));
builder.Services.AddAuthorization(options =>
    options.AddPolicy("Reader", policy => policy
        .RequireAuthenticatedUser().RequireRole("Api.Reader")));
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/api/orders", () => Results.Ok(new[] { "ORDER-1001" }))
   .RequireAuthorization("Reader");
app.Run();

8. 401 oder 403?

HTTP 401 bedeutet meist, dass der Request nicht korrekt authentifiziert wurde: Das Token fehlt, ist ungültig oder für eine andere Ressource bestimmt. HTTP 403 zeigt typischerweise an, dass ein authentifizierter Aufrufer keine ausreichenden Rechte besitzt.

9. Sicherheitsregeln

Nutze HTTPS. Speichere Secrets nicht im Repository. Bevorzuge Managed Identities oder Zertifikate bei geeigneten Workloads. Setze die geringstmöglichen Berechtigungen um und erlaube nur die notwendigen Zielgruppen. Browser-Anwendungen dürfen kein dauerhaftes Client Secret enthalten; dort sind Authorization Code Flow mit PKCE oder passende Backend-Architekturen relevant.

10. Praxisübungen

Zeichne die beteiligten Rollen einer Business-Central-zu-.NET-API-Integration auf. Erkläre, warum ein Graph-Token nicht einfach bei einer eigenen API akzeptiert werden darf. Teste einen Endpoint ohne Token, mit falscher Audience und mit einer passenden Reader- beziehungsweise Editor-Rolle.

Documentation

Microsoft: Client credentials · Microsoft: Access tokens · RFC 7519 JWT