Sari la conținut

MCP authentication

Explicați autentificarea OAuth 2.0 a platformei pentru MCP, care acoperă descoperirea, reîmprospătarea tokenului, înregistrarea dinamică a clientului, CIMD, domenii de resurse și erori.

View as Markdown

platforma utilizează OAuth 2.0 pentru autentificarea MCP. Clienții interactivi pot completa automat fluxul de autorizare. Clienții care necesită o credențială statică pot utiliza un token OAuth scalabil creat în interfața de utilizare a platformei.

Ambele metode trimit un token de acces în HTTP Authorization header:

Authorization: Bearer <credential>

Un client MCP ar trebui să înceapă cu punctul final MCP pentru implementare:

  • US: https://us.probo.com/api/mcp/v1
  • EU: https://eu.probo.com/api/mcp/v1
  • Self-hosted: https://<your-host>/api/mcp/v1

An unauthenticated request returns 401 Unauthorized Cu un

RFC 9728 Protected Resource Metadata URL

:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://us.probo.com/.well-known/oauth-protected-resource"

Obțineți acea adresă URL pentru a descoperi resursa, serverul de autorizare, metoda token-ului purtătorului și domeniile de resurse acceptate:

{
  "resource": "https://us.probo.com",
  "authorization_servers": ["https://us.probo.com"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["openid", "v1:iam", "v1:risk"]
}

Răspunsul abreviat de mai sus ilustrează câmpurile, nu lista completă de domenii. Utilizați întotdeauna valorile returnate de implementare.

The authorization server publishes both discovery documents:

https://us.probo.com/.well-known/oauth-authorization-server
https://us.probo.com/.well-known/openid-configuration

Discovery oferă autorizarea implementării, token-ul, înregistrarea, revocarea, introspecția, autorizarea dispozitivului și punctele finale JWKS. De asemenea, anunță tipurile de granturi acceptate, metodele de autentificare a punctelor finale ale token-ului, metodele PKCE și domeniile.

the platform supports:

  • Authorization Code with PKCE using S256
  • Refresh tokens with offline_access
  • OAuth 2.0 Device Authorization
  • Dynamic Client Registration
  • Client ID Metadata Documents

Clienții MCP ar trebui să utilizeze descoperirea în loc să construiască URL-uri endpoint OAuth.

Clienții interactivi care au nevoie să rămână conectați ar trebui să solicite offline_accessplatforma emite un token de reîmprospătare numai dacă sunt îndeplinite ambele condiții:

  • Cererea de autorizare include offline_access scope.
  • Înregistrarea clientului include refresh_token grant type.

Când expiră tokenul de acces, trimiteți tokenul de reîmprospătare la token_endpoint advertised by discovery:

POST /api/connect/v1/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=<refresh-token>&client_id=<client-id>

o reîmprospătare reușită returnează un token de acces nou și un token de reîmprospătare nou; înlocuiți ambele valori stocate atomic și nu reutilizați tokenul de reîmprospătare anterior.

Without offline_access, utilizatorul trebuie să autorizeze din nou clientul după expirarea tokenului său de acces.

Clienţii se pot înregistra prin intermediul registration_endpoint publicitate prin descoperirea serverului de autorizare. utilizarea clientilor publici token_endpoint_auth_method: "none" și PKCE. Clienții confidențiali pot utiliza client_secret_basic or client_secret_post.

platforma acceptă identificatori de client bazate pe URL. Cu CIMD, OAuth client_id este un URL HTTPS care returnează documentul de metadate al clientului. Acest lucru permite clienților, cum ar fi asistenții AI găzduiți, să se identifice fără un ID client pre-provizionat sau secret.

Serverul de autorizare anunță suport cu:

{
  "client_id_metadata_document_supported": true
}

Un document CIMD utilizat cu platforma trebuie:

  • Să fie servit ca JSON din adresa URL HTTPS exactă utilizată ca client_id
  • Set client_id Același URL
  • Include client_name şi cel puţin o redirect_uri
  • Use token_endpoint_auth_method: "none"
  • Utilizarea URI-urilor de redirecționare HTTPS, cu excepția redirecționărilor loopback HTTP pentru clienții locali
  • Solicitați numai domenii înregistrate de implementarea platformei

Example:

{
  "client_id": "https://client.example.com/oauth/client.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://client.example.com",
  "redirect_uris": ["https://client.example.com/oauth/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "scope": "openid offline_access v1:iam:read v1:risk:read"
}

Accesul OAuth este intersecția dintre domeniile acordate și permisiunile platformei utilizatorului. Un domeniu nu oferă niciodată unui utilizator acces la o organizație sau la o operațiune la care contul lor nu poate accesa altfel.

Resource scopes use these forms:

  • v1:<resource>:read Granturi de citire a operațiunilor pentru o familie de resurse.
  • v1:<resource> Oferă atât lectură, cât și scriere pentru acea familie.

For example:

  • listOrganizations necesită un domeniu de aplicare precum v1:iam:read.
  • listRisks requires v1:risk:read or v1:risk.
  • Crearea sau actualizarea riscurilor necesită v1:risk.
  • Reading third parties requires v1:third-party:read or v1:third-party.

Other resource families include asset, audit, control, document, privacy, task, webhook, access-review, itam, and compliance-page. The authorization server’s scopes_supported valoarea este lista autorizată pentru o implementare.

Domeniile standard au semnificațiile lor obișnuite OAuth și OpenID Connect:

  • openid requests an OpenID Connect identity token.
  • profile and email request identity claims.
  • offline_access requests a refresh token.

Documentul Protected Resource Metadata promovează în mod intenționat domeniile mai largi de scriere. Documentul de descoperire a serverului de autorizare include lista completă, inclusiv :read variants.

Dacă un client MCP nu poate finaliza un flux OAuth interactiv, creați un token OAuth cuprinzător în platformă:

  1. Deschideți meniul contului și selectați OAuth tokens.
  2. Select Create token.
  3. Introduceți un nume, selectați o expirare și selectați numai domeniile de care are nevoie clientul.
  4. Creați și copiați tokenul. platforma își afișează valoarea o singură dată.

Stochează tokenul în mecanismul secret sau variabil al mediului al clientului.Pentru clienții care susțin extinderea mediului:

Pentru clienții care susțin extinderea mediului:

{
  "mcpServers": {
    "probo": {
      "url": "https://us.probo.com/api/mcp/v1",
      "headers": {
        "Authorization": "Bearer ${env:PROBO_OAUTH_TOKEN}"
      }
    }
  }
}

Tokenul este supus atât domeniilor selectate, cât și permisiunilor contului care l-a creat. Creați un token separat pentru fiecare client sau mediu, astfel încât acesta să poată fi auditat și revocat independent.

A missing credential returns a discovery challenge:

WWW-Authenticate: Bearer resource_metadata="https://us.probo.com/.well-known/oauth-protected-resource"

O credențială de titular invalidă, expirată sau nerecunoscută returnează:

WWW-Authenticate: Bearer error="invalid_token", resource_metadata="https://us.probo.com/.well-known/oauth-protected-resource"

Odată ce transportul MCP este autentificat, eșecurile de autorizare sunt returnate prin apelul la instrumente:

  • insufficient scope înseamnă că tokenul OAuth nu acordă un domeniu cartografiat operațiunii solicitate.
  • permission denied înseamnă că utilizatorul autentificat nu poate efectua operațiunea pe această resursă.
  • assumption required Aceasta înseamnă că operațiunea necesită un context organizațional activ.

Modificarea formatării credențialului nu va remedia un domeniu de aplicare sau o eroare de permisiune.

Utilizați HTTPS și păstrați jetoanele în afara controlului sursă, jurnalele, prompturile de chat și fișierele de configurare MCP care vor fi partajate. Dacă un jetoan OAuth poate fi expus, revocați-l, emiteți o înlocuire, actualizați clientul și revizuiți activitatea relevantă.

Ultima actualizare: