BusDK

BusDK Update

Bus API saa salasanattoman kirjautumisen

bus-auth tuo rekisteröinnin, OTP-koodin, hyväksyntätilan ja AI Platform -tokenin samaan komentopintaan. Palvelupuolella bus-api-provider-auth hoitaa sähköpostivahvistuksen, hyväksyntäjonon ja tokenin myöntämisen.

Käyttäjän ei tarvitse hakea JWT:tä erillisestä kehittäjäpolusta. Token tulee paikallisesta tai julkaistusta Bus auth -palvelusta, ja sama token käy AI Platformin /v1-rajapintaan.

25.4.2026bus-authBus APIAI Platform

Tiiviisti

TL;DR

  • bus auth osaa rekisteröidä sähköpostin, pyytää OTP-koodin, vahvistaa sen ja näyttää hyväksyntätilan.
  • Vahvistus palauttaa auth-palvelun tokenin; erillinen token-komento pyytää hyväksytylle käyttäjälle AI Platform -tokenin.
  • Kun auth-provider on enabletty bus-api-prosessiin, kirjautumisreitit toimivat myös tuotantokäyttöön tarkoitetuissa /api/v1/auth/*- ja /api/internal/auth/*-poluissa.
  • Paikallinen compose-esimerkki käynnistää PostgreSQL:n, MailHogin ja Bus API:n auth-providerilla ilman oikeita salaisuuksia.

Uusi kirjautumispolku alkaa tavallisista Bus-komennoista:

$ bus auth --api-url http://127.0.0.1:8080 register --email user@example.com
$ bus auth --api-url http://127.0.0.1:8080 login --email user@example.com
$ bus auth --api-url http://127.0.0.1:8080 verify \
  --email user@example.com \
  --otp 123456 \
  --token-file ~/.config/bus/auth/token

Vahvistuksen jälkeen tilan voi tarkistaa samalla token-tiedostolla:

$ bus auth --api-url http://127.0.0.1:8080 \
  --token-file ~/.config/bus/auth/token \
  status
{
  "email": "user@example.com",
  "status": "waitlisted",
  "email_verified": true
}

Hyväksytty käyttäjä pyytää AI Platform -tokenin erillisellä komennolla. Auth-palvelun token ei vielä anna mallikäyttöä; se todistaa käyttäjän auth-palvelulle. AI Platform -tokenissa yleisö ja scope vaihtuvat palvelukäyttöön, esimerkiksi aud=ai.hg.fi/api ja scope=llm:proxy.

$ bus auth --api-url http://127.0.0.1:8080 \
  --token-file ~/.config/bus/auth/token \
  token
{
  "access_token": "...",
  "token_type": "Bearer",
  "account_id": "..."
}

Paikallinen kehityspolku on nyt sama kuin julkaistun palvelun perusmalli: compose käynnistää PostgreSQL:n pysyvälle tilalle, MailHogin OTP-viesteille ja bus api serve -prosessin, jossa auth-provider on kiinnitetty Bus API:n moduulipolkuun. Tämä tekee rekisteröinnistä, OTP:n lukemisesta, hyväksynnästä ja AI Platform -tokenin pyytämisestä yhden toistettavan virran.

Kun auth-provider ajetaan Bus API:n sisäisenä moduulina, OTP-reitit toimivat myös moduuliprefixin alta. Uudempi bus-api-mounttaus palvelee saman providerin lisäksi siistejä public-reittejä, kun palvelin käynnistetään asetuksilla --provider auth --enable-module auth:

POST /api/v1/auth/register
POST /api/v1/auth/otp/request
POST /api/v1/auth/otp/verify
GET  /api/v1/auth/status
POST /api/v1/auth/token
GET  /api/internal/auth/check

Näin tuotantopolku ei riipu geneerisestä /modules/auth/-osoitteesta, vaikka moduulipolku säilyy edelleen yhteensopivuuden ja sisäisen mount-mallin vuoksi. Jos vaadittu deployment-secret puuttuu, sama reitti palauttaa vakaan JSON-koodin auth_provider_unavailable sen sijaan, että virhe näkyisi epämääräisenä palvelukatkona.

Kehitysympäristössä OTP-koodin voi myös ohjata konsoliin asettamalla BUS_AUTH_OTP_SENDER=console. Silloin palvelu kirjoittaa BUS_AUTH_OTP-alkuisen rivin, jossa näkyvät kanava, vastaanottaja, koodi ja vanhenemisaika. Tuotantokäytössä OTP kuuluu sähköpostiin tai muuhun erilliseen senderiin, ei palvelulokiin.

Komennon käyttäjäpuoli on kuvattu bus-auth-dokumentaatiossa. Palvelun asetukset, PostgreSQL-tuki, MailHog-esimerkki ja providerin HTTP-pinnat löytyvät bus-api-provider-authin dokumentaatiosta.