(Nautilus · Accesso e utenti)
Registrazione, accesso, recupero della password, verifica dell'email e autenticazione a due fattori, come chiamate API. Tu disegni le schermate; Nautilus gestisce ciò che c'è dietro: sessioni, dieci provider di accesso, webhook firmati e una dashboard per i tuoi utenti. È l'Ory Kratos che potresti ospitare tu stesso, senza la configurazione Docker, il database e gli aggiornamenti.
curl -X PATCH https://api.vernesoft.com/v1/gate/identities/id_12345/metadata \
-H "Authorization: Bearer vrn_gate_•••" \
-H "Content-Type: application/json" \
-d '{"role":"admin","subscription_tier":"pro"}'(Costruirlo o ospitarlo)
Email e password sembrano una giornata di lavoro. Poi arrivano il recupero via email, la verifica, un secondo fattore, l'accesso con Google e GitHub e un modo per chiudere una sessione già emessa. Scrivere tutto questo è un costo. Ospitare un identity server generico come Keycloak è un altro: il servizio, il suo database, gli aggiornamenti e qualcuno nel tuo team che lo capisca quando si rompe.
Costruirlo o ospitarlo da te
Con Nautilus
(Funzionalità principali)
(01)
GitHub, Google, GitLab, Microsoft, Discord, Facebook, LinkedIn, Slack, Twitch e Spotify. Attiva ciascuno per account; Nautilus custodisce le app OAuth, quindi non registri nulla presso i provider. I claim tornano mappati in un'unica forma di utente.
(02)
Codici da app di autenticazione con codici di backup, attivati per account. Quando li richiedi, il gateway rifiuta una sessione che ha saltato il secondo passaggio. Oppure elimina la password: un codice monouso via email, valido 15 minuti.
(03)
Elenca le sessioni attive di un utente con l'indirizzo IP e lo user agent di ogni dispositivo, quando Kratos è riuscito a rilevarli. Chiudi una sessione, o tutte le sessioni di un'identità, con una sola chiamata.
(04)
Tieni sull'utente il nome del piano, un'azienda o un flag di onboarding. Un PATCH unisce ciò che invii e lascia intatto il resto. L'utente può leggerlo, quindi niente segreti, e Nautilus non applica ciò che ci metti.
(05)
Registrazioni, accessi, cambi di password, verifica dell'email, disattivazione ed eliminazione arrivano al tuo endpoint, firmati con lo schema Svix. Le consegne fallite ricevono fino a otto tentativi in circa 28 ore, e ogni tentativo viene registrato e può essere reinviato dalla dashboard.
(06)
Recupero della password, verifica dell'email e modifiche alle impostazioni funzionano come brevi flussi API: ne avvii uno, invii il codice o il nuovo valore. Tu mostri il modulo; Nautilus invia l'email e controlla la risposta.
(Un solo prodotto)
Webhook, job cron e accesso con Telegram stanno dietro lo stesso account e la stessa dashboard. In pratica, gli eventi di accesso raggiungono il tuo server con la stessa consegna firmata di qualsiasi altro webhook, e ogni chiave API è limitata a un solo compito: la chiave che usa il tuo servizio di accesso non può quindi pianificare job né inviare webhook.
(Esperienza sviluppatore)
Le schede mostrano la stessa richiesta in curl e negli SDK Node, Python, PHP e Rust. Il tenant arriva dalla chiave API, quindi non passi mai un id dell'account.
curl -X PATCH https://api.vernesoft.com/v1/gate/identities/id_12345 \
-H "Authorization: Bearer $VERNE_GATE_KEY" \
-H "Content-Type: application/json" \
-d '[
{ "op": "replace", "path": "/traits/locale", "value": "fr" }
]'(FAQ)
No. Keycloak è un identity server generico con SAML, federazione LDAP, pagine di accesso personalizzabili e console di amministrazione. Nautilus fa un lavoro più stretto: accesso e account utente per i clienti di un prodotto SaaS, dietro un'API HTTP senza schermate proprie. Se ti serve SAML o il single sign-on per clienti enterprise, tieni Keycloak. Se lo usi per l'accesso con password, Google e GitHub, il recupero e i due fattori, questa è la parte che puoi smettere di ospitare. Organizzazioni, ruoli e membri sono disponibili tramite l'API; la dashboard non ha ancora una schermata per loro, e i ruoli non viaggiano nei token, quindi il tuo backend li legge dall'API.
Sì, le schermate. Nautilus restituisce ogni passaggio come risposta API e il tuo codice invia ciò che l'utente ha digitato, così i moduli sembrano il resto del tuo prodotto. Ciò che smetti di costruire è tutto quello che c'è dietro: archiviazione delle password, email di recupero e verifica, sessioni, accessi con i provider. Se vuoi una pagina di accesso ospitata e personalizzabile, Keycloak ce l'ha e questo no.
Ogni consegna porta gli header svix-id, svix-timestamp e svix-signature: una firma HMAC-SHA256 su id, timestamp e body grezzo. Controllala con la libreria Svix ufficiale e open source, che esiste per Node, Python, Go, Rust, PHP, Java, Ruby, C# e Kotlin, invece di scrivere il controllo da te. Le consegne fallite vengono ritentate e possono essere reinviate dalla dashboard.
3.000 richieste al mese sono gratis, senza carta. Creare, leggere, aggiornare ed eliminare utenti conta in quel totale; i flussi di accesso, registrazione e recupero no. Starter costa 19 € per 50.000 richieste, Pro 79 € per 300.000, ed entrambi possono aggiungere pacchetti da 10.000 a 3 €. Il piano gratuito non ha pacchetti. L'elenco aggiornato è nella pagina dei prezzi.
Ory Kratos, l'identity server open source, come un unico deployment condiviso per tutti gli account. La dashboard, le chiavi API, i webhook e il controllo che tiene gli utenti di un account lontani da quelli di un altro sono nostri, sopra. Il prezzo della condivisione: lo schema utente è fissato a un'email, una lingua e il tuo campo JSON, e non puoi cambiare la configurazione propria di Kratos. Il motore è aperto: se questo non ti basta più, lo stesso software gira sui tuoi server.
In database sui nostri server in Francia, presso OVHcloud: identità, sessioni e i tuoi metadati personalizzati.
(Inizia oggi)
Registrazione, accesso, recupero e due fattori per i tuoi clienti, da un'unica API HTTP. Crea un account e le prime 3.000 richieste di ogni mese sono gratis.
Che cosa resta tuo
È con l'autenticazione che di solito comincia il lock-in, perché chi possiede il record utente finisce per modellare il modello dei dati attorno a esso. Nautilus non te lo chiede. Chi può accedere vive qui; i record dei tuoi clienti, gli ordini e tutto il resto restano nel Postgres, MySQL o Mongo che già usi. Non c'è uno schema nostro a cui le tue tabelle debbano adattarsi e nulla da migrare.
Sotto c'è Ory Kratos, open source e non modificato. Gestiamo noi il server e gli aggiornamenti, e teniamo quel deployment volutamente noioso, ma il motore è uno che potresti far girare tu. Un fornitore di autenticazione che si può lasciare è un'altra proposta rispetto a uno che non si può lasciare, ed è per questo che nominiamo il motore invece di nasconderlo.
Gira sui nostri server in Francia, che è la prima domanda che fanno molti acquirenti europei. Il piano gratuito è di 3.000 richieste al mese, e i flussi di accesso, registrazione e recupero non vi rientrano, quindi un pomeriggio basta per capire se questo si adatta allo stack che hai già.