MCP-ServerAuthentifizierung

MCP-Authentifizierung

Authentifiziere dich beim Nomadfiling-MCP-Server mit API-Schlüsseln oder OAuth 2.1 mit PKCE — Token-Formate, Laufzeiten und der vollständige Autorisierungsablauf.

POST /tools/call HTTP/1.1
Host: mcp.nomadfiling.com
Content-Type: application/json
Authorization: Bearer nf_invalid_token_value

{
  "jsonrpc": "2.0",
  "id": "req_unauth_01",
  "method": "tools/call",
  "params": {
    "name": "get_filing_status",
    "arguments": {
      "filingId": "fil_9m2x8q1p"
    }
  }
}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp", resource_metadata="https://mcp.nomadfiling.com/.well-known/oauth-protected-resource"
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32001,
    "message": "Unauthorized"
  },
  "id": "req_unauth_01"
}
POST /register HTTP/1.1
Host: mcp.nomadfiling.com
Content-Type: application/json

{
  "redirect_uris": [
    "https://studio.acme.dev/oauth/callback"
  ],
  "client_name": "Acme MCP Studio",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_method": "none"
}
{
  "client_id": "mcp_client_example_1234567890abcdef",
  "client_id_issued_at": 1734567890,
  "redirect_uris": [
    "https://studio.acme.dev/oauth/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none",
  "client_name": "Acme MCP Studio"
}
POST /token HTTP/1.1
Host: mcp.nomadfiling.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=mcp_code_example_1234567890abcdef&redirect_uri=https%3A%2F%2Fstudio.acme.dev%2Foauth%2Fcallback&client_id=mcp_client_example_1234567890abcdef&code_verifier=example_code_verifier_value
{
  "access_token": "mcp_at_example_7jd3p4n8q2r6s1t5v9w0x3y6",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "mcp_rt_example_1234567890abcdef",
  "scope": "mcp"
}
POST /token HTTP/1.1
Host: mcp.nomadfiling.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=mcp_rt_example_1234567890abcdef
{
  "access_token": "mcp_at_example_rotated_7jd3p4n8q2",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "mcp_rt_example_rotated_abcdef1234567890",
  "scope": "mcp"
}

Eine Authentifizierungsmethode wählen

Authentifiziere MCP-Anfragen entweder mit einem NomadFiling-API-Schlüssel oder einem OAuth-2.1-Zugriffstoken. Verwende API-Schlüssel für Server-zu-Server-Zugriff, den du direkt steuerst, und OAuth, wenn du einen Client baust, der Nutzer anmeldet und delegierten Zugriff benötigt.

initialize, tools/list und ping erfordern keine Authentifizierung. tools/call erfordert gültige Bearer-Anmeldedaten und gibt 401 Unauthorized zurück, wenn die Authentifizierung fehlschlägt.

Verwende einen API-Schlüssel, wenn dein MCP-Client in einer vertrauenswürdigen Umgebung läuft und du keinen Zustimmungsablauf für Endnutzer benötigst.

Header-Format

Authorization: Bearer nf_example_9xmk7q2r4b7m8n2p6t1v5c8a

Serverprüfung

  • Prüft, dass das Token mit nf_ beginnt
  • Berechnet den SHA-256-Hash des Roh-Tokens
  • Vergleicht diesen Hash mit api_keys.key_hash
  • Prüft, dass die Zeile in api_keys existiert
  • Prüft, dass expires_at entweder null oder in der Zukunft liegt
  • Aktualisiert api_keys.last_used_at asynchron
  • Gibt bei Erfolg user_id zurück, bei Fehler null

Authentifizierte Anfragen senden

Übergib die Anmeldedaten im Header Authorization als Bearer-Token. Der MCP-Server akzeptiert dasselbe Header-Muster für beide Authentifizierungsmethoden.

curl https://mcp.nomadfiling.com/tools/call \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer nf_example_9xmk7q2r4b7m8n2p6t1v5c8a" \
  -d '{
    "jsonrpc": "2.0",
    "id": "req_7aK2mP",
    "method": "tools/call",
    "params": {
      "name": "get_filing_status",
      "arguments": {
        "filingId": "fil_9m2x8q1p"
      }
    }
  }'

Wenn die Authentifizierung erfolgreich ist, wird die Anfrage mit der authentifizierten user_id im Kontext an das ausgewählte Tool weitergeleitet. Wenn die Authentifizierung fehlschlägt und die Methode tools/call ist, gibt der Server eine Authentifizierungsaufforderung zurück.

Einen NomadFiling-API-Schlüssel verwenden

API-Schlüssel sind die einfachste Option für Backend-Dienste, Skripte und private Automatisierungen. Jeder Schlüssel wird einmal in der NomadFiling-App erstellt, und auf dem Server wird nur sein Hash gespeichert.

Der Klartext-API-Schlüssel wird einmal angezeigt, wenn du ihn erstellst. Speichere ihn in deinem Secret Manager, bevor du den Erstellungsdialog verlässt.

Einen API-Schlüssel erstellen

Erzeuge API-Schlüssel in der NomadFiling-App unter /de/account/api-keys. Gib einen Namen für den Schlüssel ein, erzeuge ihn und kopiere den Klartextwert, bevor du den Dialog schließt.

Ein gültiger API-Schlüssel hat das Format nf_, gefolgt von 64 hexadezimalen Zeichen. Die vollständige Zeichenkette ist einschließlich Präfix 67 Zeichen lang.

nf_example_9xmk7q2r4b7m8n2p6t1v5c8a

API-Schlüssel-Format und Validierung

header
Authorizationstring
Required

Bearer-Token in der Form Bearer nf_.... Der Server authentifiziert nur den Roh-Token-Wert nach dem Präfix Bearer .

raw token lengthstring

32 Zufallsbytes, nach dem Präfix als 64 hexadezimale Zeichen kodiert.

stored valuestring

SHA-256-Hash des vollständigen Roh-Tokens, gespeichert in api_keys.key_hash.

expiry checktimestamp or null

Die Authentifizierung gelingt nur, wenn expires_at null ist oder später als die aktuelle Zeit liegt.

usage trackingtimestamp

Der Server aktualisiert api_keys.last_used_at nach erfolgreicher Authentifizierung asynchron.

Ergebnis der API-Schlüssel-Authentifizierung

user_idstring
Required

Nutzerkennung, die der passenden Zeile in api_keys zugeordnet ist.

Wenn die Validierung fehlschlägt, gibt der API-Schlüssel-Authenticator null zurück. Für tools/call schlägt die Anfrage dann mit der zuvor gezeigten Antwort 401 Unauthorized fehl.

OAuth 2.1 mit PKCE verwenden

OAuth 2.1 ergänzt Client-Registrierung, Nutzerzustimmung, kurzlebige Zugriffstoken und rotierende Refresh-Token. NomadFiling unterstützt den Authorization-Code-Grant und den Refresh-Token-Grant.

Verwende PKCE für jeden öffentlichen Client. Der Server unterstützt sowohl S256 als auch plain, aber S256 ist die sicherere Wahl.

OAuth-Endpunkte

EndpunktMethodeZweck
/registerPOSTEinen OAuth-Client registrieren
/authorizeGETDen Autorisierungsablauf starten
/approvePOSTNach Nutzerfreigabe einen Autorisierungscode erstellen
/tokenPOSTEinen Autorisierungscode oder ein Refresh-Token eintauschen

Vollständiger OAuth-Ablauf

Registriere deinen Client

Sende eine Anfrage an /register mit mindestens einer Redirect-URI. Der Server erstellt eine Client-ID mit dem Präfix mcp_client_ und bei Bedarf ein Client-Secret mit dem Präfix mcp_secret_.

Dein Client ist bereit, wenn du eine 201-Antwort mit client_id erhältst. Speichere diesen Wert, weil du ihn für jeden späteren Schritt benötigst.

Leite den Nutzer zur Autorisierung weiter

Sende den Nutzer zu /authorize mit Client-ID, Redirect-URI, Response-Typ und PKCE-Challenge. Der Server prüft den Client und gibt dann eine 302-Weiterleitung zu https://app.nomadfiling.com/oauth/authorize aus, wo der Nutzer den Zustimmungsbildschirm sieht.

https://mcp.nomadfiling.com/authorize?client_id=mcp_client_example_1234567890abcdef&redirect_uri=https%3A%2F%2Fstudio.acme.dev%2Foauth%2Fcallback&response_type=code&state=example_state_value&code_challenge=example_code_challenge_value&code_challenge_method=S256&scope=mcp

Nach der Freigabe sendet die App ein POST an /approve, erstellt einen Autorisierungscode mit dem Präfix mcp_code_ und leitet den Nutzer mit den Query-Parametern code und state zu deiner redirect_uri zurück.

Tausche den Autorisierungscode gegen Token

Rufe /token mit grant_type=authorization_code, dem Autorisierungscode, derselben Redirect-URI, deiner Client-ID und dem PKCE-Verifier auf, wenn der Ablauf PKCE verwendet hat. Der Server prüft den Code, markiert ihn als verwendet und gibt ein Access-Token plus ein Refresh-Token zurück.

Dein Client ist authentifiziert, wenn du das zurückgegebene access_token als Authorization: Bearer mcp_at_... senden kannst und der MCP-Server eine tools/call-Anfrage akzeptiert.

Abgelaufene Zugriffstoken erneuern

Rufe /token erneut mit grant_type=refresh_token und dem aktuellen Refresh-Token auf. Der Server widerruft die alte Token-Zeile und gibt ein neues Access-Token- und Refresh-Token-Paar zurück.

Speichere das neue Refresh-Token sofort. Die Token-Rotation wird erzwungen, daher bleibt das vorherige Refresh-Token nach einer erfolgreichen Erneuerung nicht mehr gültig.

Referenz zur dynamischen Client-Registrierung

Verwende /register, um einen Client zu erstellen, bevor du den OAuth-Ablauf startest.

Request-Body

body
redirect_urisstring[]
Required

Liste erlaubter Redirect-URIs für den Client. Der Server lehnt die Anfrage mit invalid_redirect_uri ab, wenn eine Redirect-URI fehlt oder ungültig ist.

body
client_namestring

Menschenlesbarer Client-Name, der mit dem Client-Datensatz gespeichert wird.

body
grant_typesstring[]

Grant-Typen für den Client. Standard sind authorization_code und refresh_token.

body
token_endpoint_auth_methodstring

Client-Authentifizierungsmethode für den Token-Endpunkt. Standard ist none. Wenn client_secret_post gesetzt ist, erzeugt der Server ein Client-Secret und speichert nur dessen SHA-256-Hash.

Allowed values:noneclient_secret_post

Antwortfelder

client_idstring
Required

Client-Kennung mit dem Präfix mcp_client_.

client_secretstring

Client-Secret mit dem Präfix mcp_secret_. Wird nur zurückgegeben, wenn token_endpoint_auth_method nicht none ist.

client_id_issued_atinteger
Required

Unix-Zeitstempel, wann die Client-ID ausgestellt wurde.

redirect_urisstring[]
Required

Registrierte Redirect-URIs für den Client.

grant_typesstring[]
Required

Dem Client zugewiesene Grant-Typen.

response_typesstring[]
Required

Gibt immer code zurück.

token_endpoint_auth_methodstring
Required

Konfigurierte Authentifizierungsmethode für den Token-Endpunkt.

client_namestring

Menschenlesbarer Client-Name, falls bei der Registrierung angegeben.

Referenz zum Authorization-Endpunkt

Verwende /authorize, um die Client-Anfrage zu prüfen und den Nutzer in den NomadFiling-Zustimmungsablauf weiterzuleiten.

Query-Parameter

query
client_idstring
Required

Registrierte OAuth-Client-ID.

query
redirect_uristring
Required

Redirect-URI, die genau mit einer der registrierten Redirect-URIs des Clients übereinstimmt.

query
response_typestring
Required

Muss code sein.

Allowed values:code
query
statestring

Undurchsichtiger Wert, der unverändert an deine Redirect-URI zurückgegeben wird. Verwende ihn, um CSRF zu verhindern und Browserzustand zuzuordnen.

query
code_challengestring

PKCE-Code-Challenge. Wenn vorhanden, erfordert der Token-Austausch einen passenden code_verifier.

query
code_challenge_methodstring

PKCE-Prüfmethode. Standard ist plain, wenn weggelassen.

Allowed values:S256plain
query
scopestring

Angefragter Scope. Standard ist mcp.

Verhalten

Wenn die Anfrage gültig ist, gibt der Server 302 Found zurück und leitet den Browser zu https://app.nomadfiling.com/oauth/authorize weiter, wobei die Anfrageparameter weitergegeben werden. Nachdem der Nutzer den Zugriff genehmigt hat, ruft die App /approve auf, erzeugt einen Autorisierungscode und leitet den Browser mit code und state zu deiner redirect_uri.

Referenz zum Token-Endpunkt

Verwende /token sowohl für den Authorization-Code-Austausch als auch für die Refresh-Token-Rotation.

Authorization-Code-Grant

grant_typestring
Required

Muss authorization_code sein.

Allowed values:authorization_code
codestring
Required

Autorisierungscode mit dem Präfix mcp_code_.

redirect_uristring
Required

Muss mit der während der Autorisierung verwendeten und mit dem Autorisierungscode gespeicherten Redirect-URI übereinstimmen.

client_idstring
Required

OAuth-Client-ID, die den Code angefordert hat.

code_verifierstring

Erforderlich, wenn die Autorisierungsanfrage code_challenge enthalten hat. Für S256 hasht der Server den Verifier mit SHA-256 und vergleicht die base64url-Ausgabe mit code_challenge. Für plain muss der Verifier genau code_challenge entsprechen.

Refresh-Token-Grant

grant_typestring
Required

Muss refresh_token sein.

Allowed values:refresh_token
refresh_tokenstring
Required

Refresh-Token mit dem Präfix mcp_rt_.

Token-Antwortfelder

access_tokenstring
Required

Bearer-Zugriffstoken mit dem Präfix mcp_at_.

token_typestring
Required

Immer Bearer.

expires_ininteger
Required

Lebensdauer des Zugriffstokens in Sekunden. Der aktuelle Wert ist 3600.

refresh_tokenstring
Required

Refresh-Token mit dem Präfix mcp_rt_.

scopestring
Required

Gewährter Scope. Der aktuelle Wert ist mcp.

Fehler des Token-Endpunkts

HTTP-StatusFehlerBedeutung
400invalid_grantAutorisierungscode oder Refresh-Token fehlt, ist ungültig, abgelaufen, widerrufen, bereits verwendet oder stimmt nicht mit der Client-Anfrage überein
400unsupported_grant_typegrant_type wird nicht unterstützt
400invalid_requestDie Anfrage ist fehlerhaft oder erforderliche Parameter fehlen
500server_errorDer Server ist bei der Verarbeitung der Anfrage fehlgeschlagen

Token-Formate und Laufzeiten

Jeder Anmeldedatentyp hat ein festes Präfix und Speichermuster. Der Server hasht Geheimnisse vor der Suche, ausgenommen Client-IDs und Autorisierungscodes.

Token-TypPräfixRohgrößeLaufzeitSpeicherung
API-Schlüsselnf_32 Bytes, hex-kodiertKonfigurierbarSHA-256 in api_keys.key_hash
OAuth-Client-IDmcp_client_16 Bytes, base64url-kodiertPermanentKlartext in oauth_clients
OAuth-Client-Secretmcp_secret_32 Bytes, base64url-kodiertPermanentSHA-256 in oauth_clients.client_secret_hash
Autorisierungscodemcp_code_24 Bytes, base64url-kodiert5 MinutenKlartext in oauth_auth_codes
Zugriffstokenmcp_at_32 Bytes, base64url-kodiert1 StundeSHA-256 in oauth_tokens.access_token_hash
Refresh-Tokenmcp_rt_32 Bytes, base64url-kodiert30 TageSHA-256 in oauth_tokens.refresh_token_hash

Alle Token werden mit crypto.getRandomValues und base64url-Kodierung erzeugt, außer API-Schlüsseln, die nach dem Präfix nf_ hexadezimal angezeigt werden. Die Refresh-Token-Rotation wird erzwungen, daher widerruft jede erfolgreiche Erneuerung die vorherige Token-Zeile und stellt ein neues Token-Paar aus.

Sicherheitshinweise

Protokolliere keine Roh-Bearer-Token, Autorisierungscodes oder Client-Secrets. Protokolliere stattdessen Token-Präfixe, Request-IDs und Nutzer-IDs.

Wenn du einen öffentlichen Client baust, behandle client_id als öffentliche Metadaten und code_verifier, Zugriffstoken und Refresh-Token als Geheimnisse. Speichere Refresh-Token verschlüsselt und rotiere sie unmittelbar nach der Erneuerung.

FAQ

tools/call erfordert Authentifizierung. initialize, tools/list und ping sind ohne Authentifizierung erlaubt.

Verwandte Seiten