MCP authentication

platforma utilizează OAuth 2.0 pentru autentificareaMCP. 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 antetul HTTP Authorization:

Authorization: Bearer <credential>

OAuth discovery

Un clientMCPar trebui să înceapă cu punctul finalMCPpentru 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

O solicitare neautentificată returnează 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

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

https://<your-host>/.well-known/oauth-authorization-server
https://<your-host>/.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:

Cod de autorizare cu PKCE utilizând S256
Reîmprospătați jetoanele cu offline_access
OAuth 2.0 Device Authorization
Dynamic Client Registration
Client ID Metadata Documents

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

Access token lifetime and refresh

Clienții interactivi care trebuie să rămână conectați ar trebui să solicite offline_access. platforma emite un token de reîmprospătare numai atunci când sunt îndeplinite ambele condiții:

Cererea de autorizare include domeniul ___ZBT_I18N_RUNTIME_BLOCK_184__.
Înregistrarea clientului include tipul de grant ___ZBT_I18N_RUNTIME_BLOCK_185__.

Când expiră tokenul de acces, trimiteți tokenul de reîmprospătare la token_endpoint anunțat de descoperire:

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.

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

Client registration

Dynamic Client Registration

Clienții se pot înregistra prin intermediul registration_endpoint anunțat de descoperirea serverului de autorizare. Clienții publici utilizează token_endpoint_auth_method: "none" și PKCE. Clienții confidențiali pot utiliza client_secret_basic sau client_secret_post.

Client ID Metadata Documents (CIMD)

cu CIMD, OAuth client_id este un URL HTTPS care returnează documentul cu metadate al clientului.

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
Setarea client_id la aceeași adresă URL
Include client_name și cel puțin unul 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"
}

Scopes

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 oferă operațiuni de citire pentru o familie de resurse.
v1:<resource> oferă atât operațiuni de citire, cât și de scriere pentru acea familie.

For example:

listOrganizations necesită un domeniu IAM cum ar fi v1:iam:read.
listRisks necesită v1:risk:read sau v1:risk.
Crearea sau actualizarea riscurilor necesită v1:risk.
Citirea terților necesită v1:third-party:read sau v1:third-party.

Alte familii de resurse includ asset, audit, control, document, privacy, itam, compliance-page, , itam

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

openid solicită un token de identitate OpenID Connect.
profile și email cereri de identitate.
offline_access requests a refresh token.

Documentul de descoperire a serverului de autorizare include lista completă, inclusiv variantele :read.

OAuth tokens for static configuration

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

Deschideți meniul contului și selectați OAuth tokens.
Select Create token.
Introduceți un nume, selectați o expirare și selectați numai domeniile de care are nevoie clientul.
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.

Authentication errors

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 transportulMCPeste 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 î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.

Credential handling

Utilizați HTTPS și păstrați jetoanele în afara controlului sursă, jurnalele, prompturile de chat și fișierele de configurareMCPcare 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ă.