Authentifizierung und Autorisierung

Authentifizierungsmethoden

Glossia unterstützt je nach Kontext zwei Authentifizierungsmethoden.

Browser-Sitzungen

Bei der Anmeldung über die Weboberfläche nutzt Glossia eine sitzungsbasierte Authentifizierung. Sie authentifizieren sich über einen Drittanbieter (GitHub oder GitLab) unter Verwendung der Bibliothek Assent. Nach einer erfolgreichen Anmeldung wird ein Session-Cookie gesetzt und für nachfolgende Anfragen verwendet.

Bearer-Token (OAuth 2.1)

Für den API-Zugriff (beispielsweise über das CLI oder andere Tools) implementiert Glossia OAuth 2.1 mit dem Authorization Code Flow und PKCE. Clients erhalten ein Bearer-Token und übergeben dieses im Header Authorization:

Authorization: Bearer <access_token>

OAuth 2.1-Ablauf

1. Dynamische Client-Registrierung

Clients registrieren sich selbst, indem sie POST /oauth/register mit ihren Metadaten aufrufen. Dies folgt RFC 7591.

{
  "client_name": "My Tool",
  "redirect_uris": ["http://localhost:8080/callback"],
  "grant_types": ["authorization_code"]
}

Der Server gibt client_id und client_secret zurück.

2. Autorisierungsanfrage

Der Client leitet den Benutzer mit PKCE-Parametern an /oauth/authorize weiter:

GET /oauth/authorize?response_type=code&client_id=<id>&redirect_uri=<uri>&code_challenge=<challenge>&code_challenge_method=S256&state=<state>

PKCE ist für alle Clients erforderlich. Es wird nur die Challenge-Methode S256 unterstützt.

3. Token-Austausch

Nachdem der Benutzer zugestimmt hat, tauscht der Client den Autorisierungscode an der Stelle POST /oauth/token gegen Token aus:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=<code>&redirect_uri=<uri>&client_id=<id>&code_verifier=<verifier>

Die Antwort enthält ein Access-Token und optional ein Refresh-Token.

4. Token-Aktualisierung

Wenn ein Access-Token abläuft, verwenden Sie das Refresh-Token:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=<token>&client_id=<id>&client_secret=<secret>

Scopes

Scopes steuern, welche Aktionen ein Token ausführen kann. Sie folgen dem Muster object:action.

Autorisierungsmodell

Glossia erzwingt zwei Ebenen für die REST-API und den MCP-Server:

1. Scope-Prüfung: Das Access-Token muss den erforderlichen Scope object:action enthalten.
2. Richtlinie auf Ressourcenebene: Der aktuelle Benutzer muss für die spezifische Ressource über Glossia.Policy autorisiert sein.

Scopes stellen die maximale Berechtigung eines Tokens dar. Das Richtliniensystem erzwingt die tatsächliche Berechtigung für eine spezifische Ressource.

Rollen

Rollenberechtigungen

Discovery-Endpunkte

Glossia veröffentlicht Metadaten unter standardmäßigen, bekannten URLs, sodass Clients Endpunkte automatisch erkennen können.

Metadaten des OAuth-Autorisierungsservers (RFC 8414)

GET /.well-known/oauth-authorization-server

Gibt den Aussteller (Issuer), Endpunkte, unterstützte Scopes, Grant-Typen und Code-Challenge-Methoden zurück.

Metadaten für geschützte Ressourcen (RFC 9728)

GET /.well-known/oauth-protected-resource

Gibt die Ressourcenkennung, Autorisierungsserver, unterstützte Scopes und Bearer-Methoden zurück.

Ratenbegrenzung

OAuth-Endpunkte sind pro IP-Adresse ratenbegrenzt:

Bei einer Ratenbegrenzung gibt der Server HTTP 429 (Too Many Requests) zurück.