Authentifizierung an API bei aktivierter 2FA



  • Hallo,

    gibt es eine Möglichkeit sich an der ChurchTools API zu authentifizieren wenn der Benutzer 2FA aktiviert hat?

    Von der ajax/login Schnittstelle bekomme ich momentan folgende Rückmeldung:

    {'status': 'fail', 'data': 'Login Fehlgeschlagen. User hat die 2-Faktor Authentifizierung aktiviert.'}
    

    Gibt es da einen zusätzlichen Parameter der nicht dokumentiert ist oder den ich übersehen habe?

    Viele Grüße,
    Simon



  • vielleicht noche eine kleine Hintergrund-Info warum API mit 2FA:

    Wir verwenden ChurchTools als Backend für das CMS unserer Internetseite indem wir die Benutzer über die ajax/login API authentifizieren.



  • Sorry, dass ich hier reingrätsche - wie habt ihr die Verbindung CMS ChurchTools realisiert? Rein interessehalber.



  • @stefanbe unser CMS basiert auf dem Python Web-Framework Django. Wir haben hier ein eigenes Auth-Backend implementiert. Das sieht ungefähr so aus:

    class ChurchToolsBackend:
        def authenticate(self, request, username=None, password=None):
            if not (username or password):
                return None
    
            params = {"q": "login/ajax"}
            data = {"func": "login", "email": username, "password": password}
            resp = requests.post(settings.CHURCHTOOLS_URL, params=params, data=data)
            resp.raise_for_status()
            payload = resp.json()
    
            if payload["status"] == "success":
                # Normalize the username to not have duplicates
                username = username.lower()
                try:
                    user = User.objects.get(username=username)
                except User.DoesNotExist:
                    user = User(username=username)
                    user.save()
                return user
            return None
    


  • Dürfte über die neue API laufen... also in die Richtung von:
    https://churchtools.eg-p.de/api/login mit den POST feldern username, password, rememberMe.

    wenn 2FA aktiviert ist ist die antwor

    {
        "data": {
            "status": "totp",
            "message": "2-Factor Authentication activated. TOTP needed.",
            "personId": 1
        }
    }
    

    dann muss man an https://churchtools.eg-p.de/api/login/totp die parameter code (direkt der 2FA code, den man normal eingibt) und personId senden und erhält bei erfolg:

    {
        "data": {
            "status": "success",
            "redirectTo": ""
        }
    }
    


  • Gibt es da auch eine halbwegs vernünftige Dokumentation zu der API?



  • @fkmm-webmaster sagte in Authentifizierung an API bei aktivierter 2FA:

    Gibt es da auch eine halbwegs vernünftige Dokumentation zu der API?

    Ja, sobald die neue API fertig ist. Siehe hier.



  • @Aquila In Teilen scheint Sie ja schon fertig zu sein, bzw. einige scheinen ja schon die verschiedenen Endpunkte zu kennen. Oder ist das "invite only", reverse egineered, ...?



  • Ich hab auch noch keine Doku zu Gesicht bekommen... ich versuche mich meist erstmal damit den Netzwerk Verlauf von den Funktionen in CT anzuschauen (in den meisten Browsern mit CRTL+SHIFT+I die Development Konsole öffnen und dann auf den Netzwerk Tab wechseln)

    Wenns nix hilft riskiere ich einen Blick in den Code, den wir dank self-hosting ja zur Verfügung haben... (DISCLAIMER: ich weiß nicht, wie gern das von CT gesehen wird)

    Außerdem: Undokumentierte API Funktionen sind normal u.a. nicht dokumentiert, weil es sein kann, dass sie sich bald nochmal stark ändern können... (ohne größere Notiz) - wollts nur erwähnt haben...



  • @fodinabor Danke für die Info. Leider hosten wir nicht selber :(

    Ich fände es gut die API zu dokumentieren und einfach mit einem Disclaimer zu versehen. So macht man das normalerweise (z.B. GitHub)

    Damit kann man auch User-Feedback sammeln und nicht einfach etwas entwickeln das dann am Ende nur den eigenen Anforderungen genügt, aber keine wirkliche API ist.


  • ChurchToolsMitarbeiter

    Wenn man automatisiert den Login machen will ist natürlich so ein zweiter Faktor sehr unpraktisch, weil man den ja nicht automatisiert bereitstellen kann.

    In so einem Fall kann man z.B. einfach das Login Token nutzen um eingeloggt zu sein.
    Dazu muss man auch immer die user_id angeben

    Das Login_token kann man bei jedem Request mitschicken.
    Z.B. So:

    https://testdavid.church.tools/api/whoami?login_token=$LOGIN_TOKEN&user_id=$USER_ID

    Man kann es auch nur beim ersten Request mitschicken und dann die Session verwenden.



  • @davidschilling der Login ist nicht automatisiert. Wir prüfen lediglich über die CT-API ob die Login-Daten eines Benutzers korrekt sind. Nun kann ich den Benutzer zwar nach dem 2FA Code fragen, aber diesen nicht über die API verifizieren (zumindest nicht über die Legacy-API).

    Der Token-Login bringt mir in diesem Fall nichts.

    Wäre es nicht möglich eine Beta-Version der API Dokumentation online zu stellen?




  • ChurchToolsMitarbeiter

    Wie oben schon jemand erwähnt hat ist diese Api aktuell in Entwicklung.

    Wir werden dafür eine Dokumentation herausbringen. Aber die ist noch nicht fertig.
    Wir wollen auch keine Dokumentation für eine Api herausbringen die sich noch ändern kann, weil sich sonst zu viele schon auf diese Api verlassen.



  • @fkmm-webmaster für den aktuellen Fall einfach die URLs verwenden, die schon genannt wurden.. was super zum testen der Parameter funktioniert ist Postman.
    Sonst einfach nachfragen... finde die meisten Sachen mittlerweile recht schnell..

    @davidschilling ich muss tatsächlich sagen, dass ich auch für eine Beta Dokumentation wäre... einfach irgendwo sichtbar anzeigen, dass sich das ändern kann und wird.. dadurch, dass funktionen, wie das Anmelden mit 2FA nicht mehr über die alte API durchführbar sind, macht es in meinen Augen notwendig über die Möglichkeit der neuen API zu informieren.



  • Wie ich oben geschrieben habe, ist das übliche Vorgehen, die API als Beta oder unstable zu veröffentlichen. So macht es z.B. GitHub.

    Das Nutzer die CT selber hosten sich die notwendige Infos aus dem source code ziehen können führt zu einer Zweiklassengesellschaft.

    Wie oben auch angemerkt denke ich daß die Rückmeldung von Usern bezüglich der API während der Entwicklung wichtig ist. Sonst hat man zwar eine Schnittstelle die aber vielleicht nicht das wiederspiegelt was man als Nutzer benötigt.



  • @fodinabor sagte in Authentifizierung an API bei aktivierter 2FA:

    Sonst einfach nachfragen... finde die meisten Sachen mittlerweile recht schnell..

    Danke für das Angebot ;)



  • @davidschilling sagte in Authentifizierung an API bei aktivierter 2FA:

    https://testdavid.church.tools/api/whoami?login_token=$LOGIN_TOKEN&user_id=$USER_ID

    Authentifizierung im GET Parameter? Echt jetzt?



  • @fodinabor

    1. HTTPS
    2. Token


  • @Marcel

    1. https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
      ja, ich weiß, das wird selten im Browser direkt verwendet werden, es fördert aber unsichere Nutzung der API, Webserver Logs bleiben und einige Nutzer werden möglicherweise die API aus einem Firmennetz / Rechenzentrum raus aufrufen, wo es üblich ist Traffic zu analysieren und HTTP(S) Requests zu loggen... Instagram hatte da letztens Spaß:
    1. Das Token ersetzt das Passwort perfekt... User ID + Token == Username + Passwort
      Du kannst dich vll. nicht direkt in der CT Oberfläche anmelden, hast über die API aber exakt die gleichen Rechte.


  • @fodinabor doch damit kannst dich auch direkt in CT anmelden, musst dir nur die Cookies kopieren.

    Wenn man CT normal nutzt, läuft die Auth über die Cookies und nicht über Query Params.

    Wenn man die API entsprechend nutzt, kann es eine durchaus legitime Möglichkeit sein, den Token via Query Param zu verschicken. In der Annahme, dass CT hier richtig loggt ;)

    Mal anders rum, die von dir genannten Dinge sind Angriffe auf die TLS Verbindung. Wenn man da reinschauen kann, dann kann man auch noch den Request Body anschauen.



  • @Marcel hab grad nicht dran gedacht, ist ja noch besser :D

    klar, wenn CT richtig loggt.. sonst gibts immer noch paar Gemeinden, die hosten (lassen), wo vermutlich die vollen GET Strings geloggt werden (was ja nicht wirklich verwerflich ist) -> Tokens im Webserver Log.

    Ähm.. klar kann man. Normal wird aber nur der GET String geloggt.

    Heißt: GET Parameter tauchen sehr viel häufiger in Logs und diese Logs werden nicht unbedingt mit besonderer Sorgfalt geschützt. Ja.. die Credentials im GET Param zu haben ist sehr convenient, da man sich um sehr viel weniger kümmern muss.. aber:

    • die meisten HTTP client APIs sind mittlerweile ausgereift und einfach genug mit POST zu verwenden
    • HTTP Header setzen ist ähnlich schnell gemacht, da könnte man dann mit Bearer Token arbeiten (oder gleich auf OAuth2 setzen), dann gehen auch weiterhin GET Requests nur halt, dass die Authentifizierungs informationen nicht in der URL enthalten sind.

    Alles was ich sagen will, ist dass ich es für eine neu entworfene RESTful API eher schade finde, dass solche eher schlüpfrigen Entscheidungen getroffen werden...