Amint azt a blog.hasura.io oldalon található egyéb blogbejegyzésekből is tudhatja, a Hasura különféle típusú hitelesítést támogat, és a következő blogbejegyzésben szeretném bemutatni, milyen hitelesítési lehetőségek vannak a Hasura éles használatakor.

A következő dolgokról fogunk beszélni:

GraphQL-végpont biztosítása

Auth Webhooks

  • „Hogyan kezdjük el az egyéni webhook használatát”
  • "A Hasura beállítása hitelesítési webhook segítségével"

Hitelesítés JWT használatával

  • "Egyéni JWT szerver"
  • "Auth0"
  • "Firebase"
  • "AWS Cognito"

Hasura engedélyrendszer

A GraphQL végpont biztosítása

A Hasura-motor új példányának létrehozásakor valószínűleg látta a Végpont biztonsága lehetőséget a konzol tetején:

Ez a hivatkozás a dokumentumok szakaszhoz vezet, amely leírja, hogyan biztosíthatja a GraphQL végpontját egy HASURA_GRAPHQL_ADMIN_SECRET környezeti változó átadásával. Függetlenül attól, hogy Dockert, Heroku-t vagy bármi mást használ, ez lesz az első lépés, amelyet meg kell tennie.

Tehát most, ha megpróbál hozzáférni a konzolhoz, egy egyszerű „bejelentkezési” oldalt fog kapni, amely megkéri, hogy adja meg a titkát.

A ADMIN_SECRET név azt sugallja, hogy ha átadja azt a kérés fejlécében, akkor adminisztrátori jogosultságokat ad az API-fogyasztónak. Ezért fontos, hogy csak kiszolgálóról szerverre történő interakciókhoz használja, például kiszolgáló nélküli funkcióktól stb.

Tehát ez nem valódi hitelesítés. Ez csak a végpontod biztosítását jelenti. Most mi a helyzet a hitelesítéssel, és mi a megfelelő hitelesítési módszer az Ön számára?

Használhatja a Firebase-t, az Auth0-t, a Firebase Functions-t, a Cognito-t, az Ön egyéni hitelesítési szerverét, valamilyen ismeretlen hitelesítési szolgáltatót stb.

Mielőtt tehát megvizsgálnánk a különböző hitelesítési implementációkat, és alább rengeteg blogbejegyzés-linket és példaalkalmazást találnánk, osszuk fel a hitelesítési típusunkat két fő típusra.

Webhookok hitelesítése

Tehát mi az a Webhook? Dióhéjban, amikor beállít egy adott környezeti változót a Hasura motorhoz, amely egyéni URL-t tartalmaz, az összes kérésfejléc (kivéve, ha a webhook GET használatára van konfigurálva) erre az egyéni URL-re kerül átadásra. Az Auth webhookban bármit megtehet, és 200 vagy 401 állapotkódot kell visszaadnia. Az 200 állapotkóddal együtt küld egy csomó változót X-HASURA-* előtaggal, amelyek használhatók a Hasura engedélyrendszerben, amelyeket később tárgyalunk.

Hogyan kezdjük el egyéni webhookunkat?

Nézzük meg a rendelkezésre álló „passport-js” webhook-katalógusminta esettanulmányát.

Kezdjük a passport-js klónozásával, és az útmutatót követve telepítjük a Heroku-ra

Most a telepítés után futtathatja az npm start funkcióval, /login vagy /signup kérések küldésével, valamint a felhasználónév és a token visszaszerzésével

curl -H "Content-Type: application/json" \                           
     -d'{"username": "test123456", "password": "test123"}' \
     https://passport-auth-hasura.herokuapp.com/login

és az eredmény ez lesz:

{
  "id": 3,
  "username": "test123456",
  "token": "dd26537df94305f35dca9605b9fade7b"
}%

Most itt az ideje beállítani a Hasura motort az imént létrehozott adatbázison

docker run -d -p 8081:8080 -e HASURA_GRAPHQL_DATABASE_URL=DATABASE_URL \
-e HASURA_GRAPHQL_ENABLE_CONSOLE=true \
-e HASURA_GRAPHQL_ADMIN_SECRET=secret \
hasura/graphql-engine:v1.0.0-alpha41

Amikor belép a konzolba, a következőket fogja látni:

amint láthatja, a users tábla akkor jött létre, amikor a passport-js sablon beállításakor knex migrációt futtattunk, de a GraphQL API-ból is szeretnénk használni, ezért feltétlenül kattintson a Track gombra, és most már lekérdezheti a felhasználókat. :

Szóval hogyan tudunk bejelentkezni? És hogyan határozzuk meg a jogosultságokat?

A passport-js példa a LocalStrategy-t használja, tehát a személynek felhasználónévvel és jelszóval kell hitelesítenie, ennek eredményeként

{
  "id": 3,
  "username": "test123456",
  "token": "dd26537df94305f35dca9605b9fade7b"
}

Tehát hogyan építsük fel ügyfélalkalmazásunkat?

Az ötlet az, hogy meg kell próbálnunk úgy bejelentkezni, mint ahogyan a konzolból bejelentkeztünk a következő végpont megnyomásával: https://{yourdeplotedpassportapp}.herokuapp.com/login

és ennek eredményeként kap tokent.
Most ezt a tokent minden kérésben át kell adnunk Hasurának engedélyezési fejlécként, így:

"Authorization": "Bearer dd26537df94305f35dca9605b9fade7b"

A Hasura beállítása auth webhook segítségével

Most már nincs hátra a webhook env változó konfigurálása és az engedélyek beállítása. Az auth webhook hozzáadásához állítsa le a docker-tárolónkat, és adja hozzá a HASURA_GRAPHQL_AUTH_HOOK env változót.

docker run -d -p 8081:8080 \ -e HASURA_GRAPHQL_DATABASE_URL=DATABASE_URL \ -e HASURA_GRAPHQL_ENABLE_CONSOLE=true \ -e HASURA_GRAPHQL_ADMIN_SECRET=secret \ -e HASURA_GRAPHQL_AUTH_HOOK=https://<heroku-app-name>.herokuapp.com/webhook \ hasura/graphql-engine:v1.0.0-alpha41

Most az történik, hogy amikor átadja a Authorization fejlécet, az átkerül az egyéni hitelesítési webhookba, és az feldolgozza.
Nézzük meg a passport-js kódot:

Amint láthatja, vagy anonymous szerepkört vagy user.id szerepet adunk át.
Most már ennek megfelelően állíthatjuk be az engedélyeinket az Engedélyek lapon.

Vessünk egy pillantást egy másik használati esetre – a Firebase függvények „auth hook”

Az ötlet ugyanaz – adja vissza a X-Hasura-User-Id és X-Hasura-Role értékeket a Hasura engedélyrendszerben való használathoz. De konkrétan ebben az auth webhookban is ellenőrizzük a Firebase segítségével, hogy az általunk átadott id_token helyes-e

Vannak más auth-webhooks kazánok, amelyeket "itt" ellenőrizhet.

Vessünk egy pillantást a webhookok hitelesítési folyamatára

  • Adja át a fejléceket Hasurának
  • A fejlécek az egyéni hitelesítési webhookba kerülnek
  • válasz 200 vagy 401.
  • 200 esetén X-Hasura-* változót kell visszaadnia a Hasura engedélyrendszerben való használathoz

Kicsit bővebben a docs-ban olvashatsz róla

Hitelesítés a JWT használatával

A JSON Web Tokens egy nyílt szabvány, és a Hasura egy konfigurációs opcióval azonnal támogatja. A HASURA_GRAPHQL_JWT_SECRET értéket a következő értékkel kell megadnia:

{
  "type": "<standard-JWT-algorithms>",
  "key": "<optional-key-as-string>",
  "jwk_url": "<optional-url-to-refresh-jwks>",
  "claims_namespace": "<optional-key-name-in-claims>",
  "claims_format": "json|stringified_json"
}
  • type - szabványos JWT-algoritmusok - A Hasura támogatja a HS256, HS384, HS512, RS256, RS384, RS512 algoritmusokat
  • key - Nyilvános kulcs a JWT titkosításhoz.
  • jwk_url - szolgáltató JWK url. Egyes szolgáltatók ezt használják a kulcs lejáratára.
  • claims_namespace – alapértelmezés szerint a Hasura motor a „https://hasura.io/jwt/claims” névtér alatt keresi a tokenben kódolt x-hasura-* előtaggal ellátott változókat. Ha átadja a claims_namespace értéket a HASURA_GRAPHQL_JWT_SECRET részeként, akkor a Hasura motor x-hasura- változókat fog keresni ebben a névtérben

Például ezt:

"https://hasura.io/jwt/claims": {
    "x-hasura-allowed-roles": ["editor","user", "mod"],
    "x-hasura-default-role": "user",
    "x-hasura-user-id": "1234567890",
    "x-hasura-org-id": "123",
    "x-hasura-custom": "custom-value"
  }

Ha a Hasura motorhoz "claims_namespace": "customClaim" van megadva, a Hasura motor arra számít, hogy a dekódolás után customClaim-ben kell keresnie az összes x-hasura-* változót

A dokumentumokban más lehetőségek is vannak a JWT használatára vonatkozóan, de dióhéjban ez így fog kinézni:

Minden hitelesítési kiszolgálónak, amely JWT-jogkivonatot ad vissza, át kell adnia a JWT-t x-hasura-* jogcímmel a konfigurált vagy a https://hasura.io/jwt/claims névtérben.

A JWT-t a motor a HASURA_GRAPHQL_JWT_SECRET-ben megadott konfigurációt követően dekódolja, és minden x-hasura-* igényt továbbít az engedélyrendszernek.

Megjegyzés: x-hasura-default-role és x-hasura-allowed-roles kötelező

Most vessünk egy pillantást a legegyszerűbb JWT token használati eset esettanulmányára

Lépjünk a https://jwt.io/ oldalra, és válasszuk ki az algoritmust RS256

Változtassuk meg a hasznos terhelés adatait a következőre:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022,
    "myAmazingAuth": {
    "x-hasura-allowed-roles": ["editor","user", "mod"],
    "x-hasura-default-role": "user",
    "x-hasura-user-id": "1234567890",
    "x-hasura-org-id": "123",
    "x-hasura-custom": "custom-value"
  }
}

És így lesz a miHASURA_GRAPHQL_JWT_SECRETünk is

{
  "type":"RS256",
  "claims_namespace": "myAmazingAuth",
  "key": "copypasted public key"
}

Most átmegyünk a konzolra, és a tokenünket Authorization Bearer tokenként adjuk át.
x-hasura-* követeléseinket a tokenből kinyerjük, és átadjuk az Engedélyek párbeszédpanelnek, ahol beállíthatja a szerepeket, és igazán részletes hozzáférést kaphat konkrét oszlopok. Az engedélyezési rendszerről egy kicsit beszélünk

Vessünk egy pillantást az általánosan használható hitelesítési technikákra.

Egyedi JWT szerver

Futtathatja saját egyéni JWT-kiszolgálóját, amely kezeli a token generálást a Hasura egyéni követelésekkel együtt. Van egy igazán nagyszerű blogbejegyzés, amely leírja "ezt"

A szerver egy passport szerver jwt-vel, és a kódot "itt" ellenőrizheti

Auth0

Az Auth0 a JWK URL-eket és a firebase-t is használja, így van egy nagyszerű eszköz, amellyel automatikusan létrehozhatja a konfigurációt az auth0 vagy a firebase számára. "itt" tudod ellenőrizni

Az Auth0 esetében is egyéni követeléseket kell beállítani az Auth0 irányítópult Rules mezőjében

Van egy blogbejegyzés az Auth0-ról. "itt" tudod ellenőrizni

Firebase

A Firebase JWK-t is használ, így a HASURA_GRAPHQL_JWT_SECRET így fog kinézni

{
  "type":"RS512", 
  "jwk_url": "https://www.googleapis.com/service_accounts/v1/jwk/[email protected]"
}

Egyéni jogcímeket is hozzá kell adnunk a Firebase-hez, így X-Hasura-* változót is bele tudunk foglalni a kódolt tokenünkbe.

Van egy nagyszerű "blogbejegyzés", amely leírja a Firebase hitelesítési használatát.

Cognito

Az AWS Cognito használatához több lépést is meg kell tennie, hogy működjön, így bár ebben a blogbejegyzésben nem merülök el mélyebben ennek módjában, részletesebb blogbejegyzés következik. A Cognito használatának fő ötlete hasonló az Auth0-hoz vagy a Firebase-hez. Valahol meg kell határoznia az egyéni követeléseket. A Cognito esetében ez nem definiálható a felületen, de létrehozhat egyéni lambdát a token generálásakor, például:

Ebben a példában a lambdánk rendkívül egyszerű lesz:

Így adunk hozzá egyéni követeléseket. Most már észreveheti, hogy követeléseinket szigorú JSON-ként adjuk át. Ez azért történik, mert a Cognito nem támogatja a beágyazott egyéni követeléseket. Azt is láthatja, hogy egy adott felhasználót keresek, ha az adminisztrátora vagy sem, és ha igen, akkor rendszergazdai szerepkört adok vissza.

Hasura oldalon az HASURA_GRAPHQL_JWT_SECRET beállításánál át kell adnom az jwk_url és a claims_format karakterláncú JSON-t

{
"type":"RS256",
"jwk_url": "https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json",
"claims_format": "stringified_json"
}

És alapvetően ennyi. A Cognito token dekódolásra kerül, és átadódik a Hasura engedélyrendszernek

Hasura engedélyrendszer

A Hasurának nagyon részletes módszere van az engedélyek kiértékelésére. A fenti szakaszokban különböző módszereket fektettem le a Hasurával történő hitelesítésre, és bár ezek a módszerek különböztek a többitől, mindegyik ugyanazt az eredményt eredményezte. A X-Hasura-* változók átadásra kerülnek a Hasura engedélyrendszernek.

Az engedélyek első rétege a szerepkörök. A szerepek meghatározása az engedélyrendszernek átadott x-hasura-default-role és x-hasura-allowed-roles változók alapján történik.

A második réteg a x-hasura-user-id vagy bármely más, az engedélyrendszernek átadott egyéni változó alapján végzett egyéni ellenőrzések

Amint ebben a példában is látható, a bejegyzés tartalmát „custom_value”-ként ellenőrizzük, és csak ha igen, akkor engedélyezzük a felhasználó számára a mezők kiválasztását. Ez azt jelenti, hogy a felhasználó csak akkor láthatja a bejegyzéseket, ha a bejegyzés tartalma megegyezik az „egyéni értékkel”.

Alternatív megoldásként beállíthatunk valami ilyesmit:

Ez azt jelenti, hogy a felhasználó csak a saját bejegyzéseit láthatja.

Összegzés

Amint a fenti összefoglalóból látható, a Hasura számos különböző hitelesítési technikát támogat, és összhangban van az iparág legjobb gyakorlataival. Ezen túlmenően a Hasura engedélyrendszer egy igazán részletes hozzáférés-vezérlési szintet biztosít, ami elengedhetetlen az éles alkalmazásokban.

Eredetileg a blog.hasura.io oldalon tették közzé 2019. április 8-án.