Authentifizierung an API bei aktivierter 2FA

fkmm-webmaster

@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

fodinabor

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": ""
    }
}

fkmm-webmaster

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

Aquila

@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.

fkmm-webmaster

@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, ...?

fodinabor

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...

fkmm-webmaster

@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.

davidschilling

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.

fkmm-webmaster

@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?

fkmm-webmaster

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

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

Wieder eine neue API für die ich keine Dokumentation habe ...

davidschilling

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.

fodinabor

@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.

fkmm-webmaster

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.

fkmm-webmaster

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

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

Danke für das Angebot

fodinabor

@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?

Marcel

@fodinabor

HTTPS
Token

fodinabor

@Marcel

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ß:

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.

Marcel

@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.

fodinabor

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

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...