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"
}
{
"error": "invalid_redirect_uri"
}
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"
}
{
"error": "invalid_grant"
}
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_keysexistiert - Prüft, dass
expires_atentwedernulloder in der Zukunft liegt - Aktualisiert
api_keys.last_used_atasynchron - Gibt bei Erfolg
user_idzurück, bei Fehlernull
Verwende OAuth 2.1, wenn dein Client Nutzerautorisierung, Zustimmung und erneuerbare Zugriffstoken benötigt.
Header-Format
Authorization: Bearer mcp_at_example_7jd3p4n8q2r6s1t5v9w0x3y6
Serverprüfung
- Prüft, dass das Token mit
mcp_at_beginnt - Berechnet den SHA-256-Hash des Roh-Tokens
- Vergleicht diesen Hash mit
oauth_tokens.access_token_hash - Prüft, dass die Zeile in
oauth_tokensexistiert - Prüft, dass
revokedfalseist - Prüft, dass
expires_atin der Zukunft liegt - Aktualisiert
oauth_tokens.last_used_atasynchron - Gibt bei Erfolg
user_idzurück, bei Fehlernull
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"
}
}
}'
const response = await fetch("https://mcp.nomadfiling.com/tools/call", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer nf_example_9xmk7q2r4b7m8n2p6t1v5c8a"
},
body: JSON.stringify({
jsonrpc: "2.0",
id: "req_7aK2mP",
method: "tools/call",
params: {
name: "get_filing_status",
arguments: {
filingId: "fil_9m2x8q1p"
}
}
})
});
const data = await response.json();
console.log(data);
import requests
response = requests.post(
"https://mcp.nomadfiling.com/tools/call",
headers={
"Content-Type": "application/json",
"Authorization": "Bearer nf_example_9xmk7q2r4b7m8n2p6t1v5c8a",
},
json={
"jsonrpc": "2.0",
"id": "req_7aK2mP",
"method": "tools/call",
"params": {
"name": "get_filing_status",
"arguments": {
"filingId": "fil_9m2x8q1p"
}
},
},
)
print(response.json())
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
Bearer-Token in der Form Bearer nf_.... Der Server authentifiziert nur den Roh-Token-Wert nach dem Präfix Bearer .
Muss nf_ sein.
32 Zufallsbytes, nach dem Präfix als 64 hexadezimale Zeichen kodiert.
SHA-256-Hash des vollständigen Roh-Tokens, gespeichert in api_keys.key_hash.
Die Authentifizierung gelingt nur, wenn expires_at null ist oder später als die aktuelle Zeit liegt.
Der Server aktualisiert api_keys.last_used_at nach erfolgreicher Authentifizierung asynchron.
Ergebnis der API-Schlüssel-Authentifizierung
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
| Endpunkt | Methode | Zweck |
|---|---|---|
/register | POST | Einen OAuth-Client registrieren |
/authorize | GET | Den Autorisierungsablauf starten |
/approve | POST | Nach Nutzerfreigabe einen Autorisierungscode erstellen |
/token | POST | Einen 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
curl -i "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
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.
Menschenlesbarer Client-Name, der mit dem Client-Datensatz gespeichert wird.
Grant-Typen für den Client. Standard sind authorization_code und refresh_token.
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.
noneclient_secret_postAntwortfelder
Client-Kennung mit dem Präfix mcp_client_.
Client-Secret mit dem Präfix mcp_secret_. Wird nur zurückgegeben, wenn token_endpoint_auth_method nicht none ist.
Unix-Zeitstempel, wann die Client-ID ausgestellt wurde.
Registrierte Redirect-URIs für den Client.
Dem Client zugewiesene Grant-Typen.
Gibt immer code zurück.
Konfigurierte Authentifizierungsmethode für den Token-Endpunkt.
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
Registrierte OAuth-Client-ID.
Redirect-URI, die genau mit einer der registrierten Redirect-URIs des Clients übereinstimmt.
Undurchsichtiger Wert, der unverändert an deine Redirect-URI zurückgegeben wird. Verwende ihn, um CSRF zu verhindern und Browserzustand zuzuordnen.
PKCE-Code-Challenge. Wenn vorhanden, erfordert der Token-Austausch einen passenden code_verifier.
PKCE-Prüfmethode. Standard ist plain, wenn weggelassen.
S256plainAngefragter 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
Autorisierungscode mit dem Präfix mcp_code_.
Muss mit der während der Autorisierung verwendeten und mit dem Autorisierungscode gespeicherten Redirect-URI übereinstimmen.
OAuth-Client-ID, die den Code angefordert hat.
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
Refresh-Token mit dem Präfix mcp_rt_.
Token-Antwortfelder
Bearer-Zugriffstoken mit dem Präfix mcp_at_.
Immer Bearer.
Lebensdauer des Zugriffstokens in Sekunden. Der aktuelle Wert ist 3600.
Refresh-Token mit dem Präfix mcp_rt_.
Gewährter Scope. Der aktuelle Wert ist mcp.
Fehler des Token-Endpunkts
| HTTP-Status | Fehler | Bedeutung |
|---|---|---|
400 | invalid_grant | Autorisierungscode oder Refresh-Token fehlt, ist ungültig, abgelaufen, widerrufen, bereits verwendet oder stimmt nicht mit der Client-Anfrage überein |
400 | unsupported_grant_type | grant_type wird nicht unterstützt |
400 | invalid_request | Die Anfrage ist fehlerhaft oder erforderliche Parameter fehlen |
500 | server_error | Der 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-Typ | Präfix | Rohgröße | Laufzeit | Speicherung |
|---|---|---|---|---|
| API-Schlüssel | nf_ | 32 Bytes, hex-kodiert | Konfigurierbar | SHA-256 in api_keys.key_hash |
| OAuth-Client-ID | mcp_client_ | 16 Bytes, base64url-kodiert | Permanent | Klartext in oauth_clients |
| OAuth-Client-Secret | mcp_secret_ | 32 Bytes, base64url-kodiert | Permanent | SHA-256 in oauth_clients.client_secret_hash |
| Autorisierungscode | mcp_code_ | 24 Bytes, base64url-kodiert | 5 Minuten | Klartext in oauth_auth_codes |
| Zugriffstoken | mcp_at_ | 32 Bytes, base64url-kodiert | 1 Stunde | SHA-256 in oauth_tokens.access_token_hash |
| Refresh-Token | mcp_rt_ | 32 Bytes, base64url-kodiert | 30 Tage | SHA-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.