De ce integrarea OAuth devine o problemă n² imposibil de rezolvat?
Fiecare aplicație trebuie să se înregistreze ca client OAuth pentru orice altă aplicație. În cel mai bun caz, înregistrarea unui client OAuth durează cinci minute de clickuri printr-un portal pentru dezvoltatori.
Culture picks
Pirkx se alătură Pri0r1ty Intelligence: o nouă eră pentru sănătatea angajaților
Washington și Beijing negociază regulile pentru atacurile cibernetice conduse de AI
Thailanda suspendă toate construcțiile de centre de date pentru o revizuire regulatoare
Ecrane portabile CarPlay devin alegerea populară pentru mașinile mai vechiDar adesea implică completarea de formulare, înregistrarea de videoclipuri demo, semnarea de documente sau, mai rău, participarea la apeluri video. Acest proces manual și nepredicibil trebuie repetat pentru fiecare aplicație pe care utilizatorii vreau să o conecteze.
Anthropic și OpenAI au întâmpinat aceeași dificultate.
Aveau nevoie să se conecteze la aplicațiile clienților lor fără să obțină sute de clienți OAuth. Astfel, au introdus o extensie poco cunoscută a specificației MCP: înregistrarea dinamică a clientilor (DCR).
De ce înregistrarea manuală a clienților OAuth te face să renunți?
În loc să cerem unui om să obțină manual un client OAuth, aplicația ta îl creează dinamic și pornește imediat fluxul OAuth spre o aplicație pe care nu a văzut-o niciodată. Acesta este visul.
În startup-ul meu, Val Town, am aflat despre DCR în timp ce construiam serverul nostru MCP, care a permis conexiunile la Val Town prin intermediul lui Claude și ChatGPT. Dar beneficiile nu se opre aici. Orice aplicație poate înregistra dinamic un client OAuth la Val Town și să se conecteze la conturile de utilizator de pe Val Town.
Pe baza acestui principiu, am creat std/oauth, o bibliotecă de middleware care adaugă autentificarea „Autentificare cu Val Town” în doar două linii de cod. Iată un exemplu complet de aplicație: ```jsx / @jsxImportSource https://esm. sh/hono/jsx / import { Hono } from „https://esm. sh/hono”; import {
getOAuthUserData, oauthMiddleware, const app = new Hono ();
De ce implementarea la Val Town pare imposibilă?
app. get („/”, async (c) => { const session = await getOAuthUserData (c. req. raw);
return c. html (` ${session?. user? `Autentificat ca ${session. user. username}`: ` Autentificare `}
export default oauthMiddleware (app. fetch); ``` Încearcă-l aici: nu este nevoie de nicio configurare suplimentară. Dacă faci click pe „remix” pe Val Town, obții o copie a acestei aplicații, iar autentificarea „Autentificare cu Val Town” funcționează imediat. Clientul OAuth al aplicației tale față de Val Town este creat în spate la prima autentificare.
De ce fiecare integrare OAuth devine un coșmar manual?
Documentele de metadate ale ID-ului client (CIMD) oferă un alt mod eficient de a descoperi și configura automat setările necesare pentru autentificare. Acestea conțin informații esențiale despre un client OAuth, cum ar fi URL-ul de redirecționare, tipurile de conexiuni permise și alte parametri critici pentru securitate și funcționalitate.
Prin utilizarea CIMD, dezvoltatorii pot reduce semnificativ efortul de configurare manuală și pot integra serviciile terțe mai rapid și mai sigur.
Aceste documente pot fi actualizate dinamic de furnizori, permițând ajustări rapide ale politicilor de securitate sau a caracteristicilor disponibile, fără intervenție directă de la aplicațiile client.
Astfel, întreaga arhitectură devine mai reacție și mai ușor de întreținut, reducând complexitatea operațională legată de conectivitatea între diferite platforme.
