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:
- „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"
- "Egyéni JWT szerver"
- "Auth0"
- "Firebase"
- "AWS Cognito"
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
vagy401
. 200
eseténX-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 algoritmusokatkey
- 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ódoltx-hasura-*
előtaggal ellátott változókat. Ha átadja aclaims_namespace
értéket aHASURA_GRAPHQL_JWT_SECRET
részeként, akkor a Hasura motorx-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.