Wir warten leider schon sehr lange darauf, dass in ChurchTools eine OAuth2.0 Schnittstelle implementiert wird. Dabei hätte diese Erweiterung so viel Potential… Die Akzeptanz in der breiten Masse der Gemeindemitglieder sich Accounts und vor allem Passwörter für verschiedene Systeme einfallen zu lassen ist sehr gering. Mit einer OAuth2.0 Schnittstelle bräuchte es nur einen einzigen ChurchTools Account über den alle Authentifzierung läuft. Es könnte ein Universum verschiedener Anwendungen für die Gemeinde entstehen. Wir könnten für unseren Gemeinden zusätzliche Module entwickeln, die wir ohne weiteres in die bestehende System-Landschaft integrieren. Ein digitales Schwarzes Brett, bei dem ich mich über einen QR-Code direkt anmelde um einen Kommentar zu hinterlassen, eine App für Musiker um ihre Noten digital zu verwalten…

Doch bis die OAuth2.0-Schnittstelle kommt wird wohl noch einige Zeit ins Land gehen. Vielleicht werden wir es auch nicht mehr miterleben. Bis dahin nutzen wir bei uns folgenden Workaround:

Der Funktionsumfang von ChurchTools für unseren Worship-Bereich reicht uns an einigen Stellen nicht aus. Deshalb haben wir dafür ein eigenes Tool in PHP mit dem Framework Laravel entwickelt.

Der Nutzer meldet sich bei unserem WorshipTool mit seiner E-Mail Adresse und Passwort an. Der ChurchTools-API Client wird mit dieser E-Mail und Passwort konfiguriert. Wenn bereits ein Nutzer in der Datenbank des WorshipTools existiert, werden die von ChurchTools abgerufenen Daten (Token, Bild-Url) aktualisiert. Existiert der Nutzer noch nicht, wird ein neuer Datensatz angelegt:

public function authenticate()
{
    $email = $this->get('email');
    $password = $this->get('password');
    $ctUrl = $this->get('ct_url');
    CTConfig::setApiUrl($ctUrl);

    try {
        CTConfig::authWithCredentials($email, $password);

        if (CTConfig::validateApiKey()) {
            $ctUser = PersonRequest::whoami();

            $laravelUser = User::where('email', $email)->where('ct_url', $ctUrl)->first();

            $updateData = [
                "name" =>  $ctUser->getFirstName(),
                "ct_id" => $ctUser->getId(),
                "ct_token" => AuthRequest::retrieveApiToken($ctUser->getId()),
                "ct_image_url" => $ctUser->getImageUrl()
            ];

            if($laravelUser == null){ // Create Model
                $updateData["email"] = $email;
                $updateData["ct_url"] = $ctUrl;
                $laravelUser = User::create($updateData);
            }else{ // Update Model
                $laravelUser->update($updateData);
                $laravelUser->save();
            }

            Auth::loginUsingId($laravelUser->id, $this->boolean('remember'));

            return redirect()->intended();
        }
    } catch (CTAuthException $exception) {
        // ignore exception
    }

    RateLimiter::hit($this->throttleKey());
    throw ValidationException::withMessages([
        'email' => trans('auth.failed'),
    ]);
}

Dabei wird nur der API-Token gespeichert und niemals das Passwort. Der API-Token läuft nach einiger Zeit wieder ab und ist einzigartig.

Die Nachteile dieser Implementierung:

• Ein Passwort-Manager erkennt das WorshipTool nicht. Der Nutzer muss also aktiv das ChurchTools Passwort raussuchen.
• Der Nutzer muss dem System vertrauen, dass es das ChurchTools Passwort nicht speichert und vertraulich mit seinen Daten umgeht.
• Es erfolgt keine Eingrenzung der Berechtigungen auf einen bestimmten Bereich. Das WorshipTool hat über die Authentifizierung mit dem API-Token alle Berechtigungen, die der Nutzer besitzt.