Keine Empfehlung für die comdirect REST API

[raupach]

Hallo zusammen,

Ich finde es sehr postiv, dass es eine umfangreiche Dokumentation und Beispiele zur comdirect REST API gibt. Mir ist durchaus bewußt, dass es im Bankenumfeld regulatorische und technische Hürden gibt, die die Bereitstellung einer von PSD2 geforderte Schnittstelle erschweren. Allerding ist die API in ihrer aktuellen Form nicht mit guten Gewissens in Desktop, Web, Mobile oder M2M integrierbar. 

Folgende Punkte halte ich für bedenklich:

Die comdirect REST API verwendet Begrifflichkeiten von OAuth 2.0 implementiert den Standard allerdings nicht. Mit OAuth 2.0 sollen Dritt-Applikation (clients) einen kontrollierten Zugang auf Resourcen des Inhabers erhalten. Dabei soll der client niemals den Inhaber (resource owner) imitieren. Das geht nur, wenn die eigentlichen Inhaber Zugangsdaten (user credentials) nicht der Dritt-Applikation zugänglich gemacht werden.

Bei der Registrierung eines clients, comdirect nennt das hier Entwicklerzugang, wird eine client_id und ein client_secret erzeugt. Mehr nicht. Es fehlt die callback_url. Ohne callback_url keinen Authorization Code Flow. Dabei ist der Authorization Code Flow eigentlich der empfohlene Weg um an ein Access Token zu gelangen. Zudem ist es nicht möglich mehrere clients zu erstellen, sondern man ist auf eine client_id festgelegt.

Stattdessen werden Access Tokens mit dem Resource Owner Password Credentials Flow in Kombination mit dem von der comdirect entwickeltem CD Secondary Flow erzeugt.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4

The resource owner password credentials grant MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client.  Even if the client is benign, this results in an increased attack surface (credentials canleak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.

Es fällt auf, dass beim Resource Owner Password Credentials Flow (siehe Dokumentation 2.1) der scope nicht vorhanden ist. Ohne scope heißt hier Vollzugriff auf alle Resourcen. Der resource owner hat keine Möglichkeiten den client einzuschränken.

Der CD Secondary Flow versucht die Unzulänglichkeiten auszumerzen. Das eigentlich Access Token aus Schritt 2.1 wird per 2FA z.B. mit der PhotoTan umständlich neu erzeugt und überschrieben. Die Session-Tan macht aus dem alten Access Token ein neues Access Token, dass alle Befugnisse einer Session-Tan umfasst. In der photoTAN App mit Push-Funktion wird eine Freigabe für "Login Persönlicher Bereich" verlangt. Es wird dem Benutzer der App nicht angezeigt, dass die TAN für eine Dritt-Applikation erstellt wurde. Die client_id fehlt.

Das Session-Objekt im HTTP-Header x-http-request-info erfüllt keine nenneswerte Funktion und kann mit einer konstanten Zeichenfolge ersetzt werden. Das Session-Objekt ist kein Schutz gegen eine Replay Attack. Den Session identifier hätte man bereits im Response von Schritt 2.1 übersenden können.

Viele Grüße

[SMT_Jan-Ove]

Hallo @raupach,

herzlich willkommen in unserer Community und vielen Dank für dein ausführliches Feedback.

Das OAuth 2.0 Verfahren mit Callback-URL verwenden wir z.B. bei Clients, die Dienstleistungen für comdirect Kunden zur Verfügung stellen, wie die Tradingplattform Guidants. Kunden-Clients, die das Privatkunden-API integrieren, können dagegen nur auf die Konten und Depots zugreifen, die an die Client-Credentials gekoppelt sind, weshalb wir uns für den Resource Owner Password Credentials Flow entschieden haben.

Im ersten Schritt (Kapitel 2.1) erhält der Aufrufer den Scope TWO-FACTOR. Dieser berechtigt lediglich dazu, eine Session-TAN gemäß PSD2 zu erzeugen. Erst mit dem CD Secondary Flow (Kapitel 2.5) werden dann die fachlichen Scopes erlaubt. Somit sind davor auch keine Abrufe von Konto-/Depotdaten möglich.

Der TAN-Text "Login Persönlicher Bereich" ist tatsächlich etwas missverständlich. Wir werden eine Anpassung veranlassen.

Beste Grüße

Jan-Ove

[raupach]

Hallo @SMT_Jan-Ove ,

vielen Dank für die Antwort und schön zu wissen, dass Ihr Euch Kritik anhört und teilweise umsetzt. 

Die Argumentation, dass clients die Dienstleistung anbieten anders gestellt werden als Kontoinhaber erschließt sich mir leider nicht.

Weiterhin schreibst Du, dass die Privatkunden-API nur auf die Konten und Depots zugreifen kann die an die Client-Credentials gekoppelt sind. Warum wurde dann im ersten Schritt nicht gleich der Client Credentials Grant verwendet? Wenn nur client_id und client_secret relevant sind dann wäre es doch sinnvoller auf Kundennummer und PIN zu verzichten? Weniger sensible daten ist doch gut, oder? 

Bleiben die Scopes. Ich würde gerne den Scope selbst einzgrenzen, z.B. nur lesenden Zugriff auf Konten. Angenommen ich schreibe eine Applikation die lediglich meine Kontoumsätze anzeigt. Dann ist es empfehlenswert die Berechtigungen auf das Notwendigste einzugrenzen. Wie es der OAuth2-Standard eigentlich erfordert. Das ist mit der comdirect REST API nicht möglich. Der von Euch selbst entwickelte CD Secondary Flow erlaubt das nicht. Der gibt vielmehr die scopes vor. 

Viele Grüße

[SMT_Jan-Ove]

Hallo @raupach,

die clientCredentials sind an den registrierten Kunden gekoppelt. Dieser kann aber mehrere Kontoverbindungen bei der comdirect haben, auf die über das API separat zugegriffen werden muss. Hierdurch reicht der ClientCredentialsFlow nicht aus.

Deinen Vorschlag bzgl. der Scope-Selektion geben wir an die entsprechende Fachabteilung weiter.

Beste Grüße

Jan-Ove

[raupach]

Hallo @SMT_Jan-Ove 

kurze Frage, kann es sein, dass das refresh_token eine sehr kurze Laufzeit hat? 10-20 Minuten?

[SMT_Jan-Ove]

Hallo @raupach,

die 20 Minuten sind tatsächlich korrekt.

Beste Grüße

Jan-Ove

[raupach]

Hallo @SMT_Jan-Ove ,

danke für die rasche Antwort. Kannst Du mal in der Fachabteilung nachfragen wie ich dann als Entwickler eine vernünftige Anwendung entwickeln soll? Ich kann doch nicht eine App schreiben, die den Anwender zwingt, sich alle 20 Minuten neu anzumelden. Und alle paar Minuten den Refresh Token Flow anzuwerfen ist ebenfalls nicht machbar. Das ist nicht im Sinne von OAuth2. Dann hätte man gleich auf das Refresh Token verzichten könnten. 

Zum Vergleich ein Refesh Token bei Google ist unbegrenzt gültig, bei den meisten anderen Anbieter die ich so kenne sind Refresh Tokens meist irgendwo zwischen 30 - 90 Tagen gültig.

Grüße

Björn Raupach

[SMT_Jan-Ove]

Hallo @raupach,

die Gültigkeiten für Access- und Refresh-Tokens sind aus Sicherheitsgründen und zum Schutz der Daten des Kunden so gewählt und entsprechen den Standard-Sessionzeiten im Persönlichen Bereich der comdirect. Auch hier müssen nach 10 Minuten Inaktivität erneut die Zugangsdaten eingegeben werden.

Beste Grüße

Jan-Ove

[raupach]

Hallo @SMT_Jan-Ove 

das beantwortet meine Frage leider nicht. Wie soll ein Entwickler damit den eine Anwendung entwickeln? Der Rest der Welt schafft es doch aus?

Bleibt leider mein Statement stehen. Die comdirect REST API ist eine nette Spielerei,  aber nicht wirklich nutzbar um dagegen Anwendungen zu entwicken. 

[SMT_Jan-Ove]

Hallo @raupach,

es gibt sowohl für kurze als auch für länger gültige Refresh Tokens gute Gründe. Ein Vorteil von langen Gültigkeiten ist, wie du beschreibst, ein größerer Komfort für den Nutzer. Kürzere Gültigkeitsdauern ermöglichen mehr Sicherheit. Refresh Tokens sind schließlich sehr mächtig und ersetzen die Eingabe von Zugangsnummer und PIN.

Als Bank sind wir hohen Sicherheitsstandards verpflichtet und die Tokens müssen in deiner Anwendung sicher verwahrt werden. Würde ein sehr lange gültiger Refresh Token öffentlich werden, könnte ein Angreifer Zugriff auf deine Bankdaten bekommen. Den Nutzungsbedingungen entsprechend wäre also eine Anwendung programmierbar, die am Anfang einer Session deine Zugangsdaten abfragt und bei Ablauf des Access Tokens automatisch mit dem Refresh Token ein neues Access Token holt. Das geht z. B. per Cronjob, wie auch schon andere Mitglieder unserer Community beschrieben haben.

Beste Grüße

Jan-Ove