Instalacja SDK

Pięć paczek, wszystkie na licencji Apache-2.0 i wszystkie opcjonalne: Kleora jest dostawcą OAuth 2.1 i OpenID Connect, więc dowolna biblioteka kliencka zadziała z nią tak samo.

@kleora-io/browser

Klient kodu autoryzacyjnego z PKCE. Bez zależności w czasie działania, wyłącznie moduły ES.

npm install @kleora-io/browser

createKleora() przyjmuje trzy opcje obowiązkowe i cztery opcjonalne:

Działającą stronę od początku do końca pokazuje szybki start.

@kleora-io/nuxt

Moduł do Nuxta 4 opakowujący SDK przeglądarkowe: automatycznie importowane composable, strażnik trasy, strona callbacku i instancja $fetch z tokenem.

npm install @kleora-io/nuxt

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@kleora-io/nuxt'],
  kleora: { issuer: '<issuer>', clientId: '<client_id>' },
})

<!-- app/pages/index.vue -->
<script setup lang="ts">
const { isAuthenticated, isLoading, login, logout } = useKleora()
const user = useKleoraUser()
</script>

<template>
  <p v-if="isLoading">Loading…</p>
  <button v-else-if="!isAuthenticated" @click="login()">Sign in</button>
  <div v-else>
    <p>{{ user?.sub }} · {{ user?.email }} · {{ user?.tenant }}</p>
    <button @click="logout({ returnTo: '/' })">Sign out</button>
  </div>
</template>

W tej konfiguracji nie ma redirectUri, bo moduł domyślnie kieruje na własną stronę callbacku pod adresem tej samej witryny — /auth/callback. Ten adres i tak trzeba zarejestrować na kliencie.

Co daje moduł:

Każdą opcję można podać ze środowiska zamiast w pliku konfiguracyjnym: NUXT_PUBLIC_KLEORA_ISSUER, …_CLIENT_ID, …_REDIRECT_URI, …_SCOPE, …_AUDIENCE, …_TENANT, …_STORAGE oraz NUXT_PUBLIC_API_BASE dla adresu API. Jedynym wyjątkiem jest callbackPath — decyduje, pod jakim adresem montuje się strona callbacku, więc ustala się go na etapie budowania.

@kleora-io/node

Sprawdzanie tokenów dostępu z cache'em JWKS, middleware dla Express i Fastify oraz typowany klient API zarządzania. Jedyna zależność w czasie działania to biblioteka JOSE; Express i Fastify są opcjonalnymi peer dependencies.

npm install @kleora-io/node

Weryfikacja nie zależy od frameworka — authenticate() przyjmuje cokolwiek, co ma własność headers.authorization, a verifyAccessToken() sam token jako tekst. Obie funkcje zwracają claimy tokenu: sub, tenant, roles, permissions, scope, env i resztę.

kleora (Python)

Ta sama weryfikacja w Pythonie, a do tego klient API zarządzania w wersji synchronicznej i asynchronicznej.

pip install kleora

import { verifyAccessToken } from '@kleora-io/node'

const claims = await verifyAccessToken(token, {
  issuer: 'https://acme.sandbox.kleora.eu',
  audience: '<client_id>',
})

from kleora import verify_access_token

claims = verify_access_token(
    token,
    issuer="https://acme.sandbox.kleora.eu",
    audience="<client_id>",
)

Obie pobierają zestaw kluczy Twojego środowiska raz, trzymają go tak długo, jak mówi odpowiedź, i odmawiają weryfikacji, gdy stanie się nieosiągalny. Żadna z nich nie czyta zmiennych środowiskowych: issuer, audience i ewentualny klucz API podajesz samodzielnie.

django-kleora

Klasa uwierzytelniania dla django-ninja, middleware, dekorator uprawnień i słownik ustawień KLEORA, zbudowane na kleora, którą paczka instaluje za Ciebie. Sama nie weryfikuje żadnego tokenu: pamięć podręczna zestawu kluczy i błędy tokenów pochodzą z kleora.

pip install django-kleora

# settings.py
INSTALLED_APPS = [..., "django_kleora"]
MIDDLEWARE = [..., "django_kleora.KleoraAuthMiddleware"]

KLEORA = {
    "ISSUER": "https://acme.sandbox.kleora.eu",
    "AUDIENCE": "<client_id>",
}

from django_kleora import KleoraAuthentication, requires_permission
from ninja import NinjaAPI

api = NinjaAPI(auth=KleoraAuthentication())


@api.get("/invoices")
@requires_permission("invoices:read")
def invoices(request):
    return {"tenant": request.kleora.tenant}

requires_permission odpowiada 401, gdy nie ma zweryfikowanego tokenu, 403, gdy token nie ma uprawnienia, i 503, gdy nie udało się odczytać zestawu kluczy issuera — to te same trzy odpowiedzi i te same dokumenty problemu, co w middleware dla Node. Middleware służy widokom, których django-ninja nie widzi: ustawia request.kleora i sam nigdy nie odrzuca żądania.

Zupełnie bez SDK

Hostowane strony i endpointy OAuth są standardowe. Wszystko, czego potrzebuje dowolny klient OpenID Connect, stoi pod adresem {issuer}/.well-known/openid-configuration, a zestaw kluczy, który tam jest wskazany, weryfikuje token. Jedynym obsługiwanym przepływem przeglądarkowym jest kod autoryzacyjny z PKCE; przepływu implicit ani hasłowego nie udostępniamy.