Client attivi e draft locali disponibili nel portal.
Workspace Overview
Una console alpha piu modulare, meno landing page
Il portal adesso separa identita, scorciatoie operative, stato backend e strumenti reali. L'obiettivo resta pragmatico: registrare client, capire il flow e testare l'integrazione.
Controllo rapido su quanti client chiedono code_challenge obbligatorio.
Il portal prova Firestore, poi degrada ai draft locali se serve.
Le mie app
OAuth clients del developer
Un elenco focalizzato sui client reali o draft che puoi gia usare per iterare sul login esterno.
Editor client
Configura il prossimo test
Quick docs
Login with myZenkai in breve
1. Authorize request
Genera una richiesta response_type=code con client_id, redirect_uri, scope, state, code_challenge e code_challenge_method=S256.
2. Callback e state
Dopo il login, il provider restituisce code e state sulla callback. Valida sempre lo state prima di continuare.
3. Code exchange
Invia il codice al token endpoint insieme a code_verifier. Se il client e pubblico, non usare un secret statico.
4. Errori tipici
Mismatch di redirect_uri, assenza di PKCE, scope non consentiti o client disabilitato sono i motivi piu frequenti di fallimento.
Snippet
Esempio rapido di exchange
curl -X POST https://auth.zenkaiverse.net/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code" \
-d "code=AUTH_CODE" \
-d "redirect_uri=https://dev.zenkaiverse.net/callback" \
-d "client_id=dev-portal-alpha" \
-d "code_verifier=YOUR_CODE_VERIFIER"Reference rapida da tenere a fianco del playground, senza perdere il contesto del flow.
Playground
Genera authorize URL
Alpha notes
Roadmap gia pronta
Fase 1
Portal minimo con session status, clients, docs rapide e PKCE playground.
Fase 2
Creazione client via callable/backend dedicato, ownership enforcement e audit trail.
Fase 3
History delle auth requests, token inspector e tool di debugging per callback ed exchange.