REST API für Privatkunden Comdirect

[panapple]

Moin zusammen,

seit noch nicht allzu langer Zeit bietet die Comdirect eine kostenlose Schnittstelle zu verschiedenen Services an und ich möchte den Abruf meiner Konto und Umsatzdaten in mein Projekt integrieren.

Leider komme ich nicht wirklich weiter und hoffe, dass sich hier jemand besser damit auskennt und mir evtl. weiterhelfen kann.

Die ausführliche Beschreibung meines Problems und meiner Fragen habe ich in dem Comdirect Forum unter diesem Link gepostet.

Unter diesem Link findet ihr die Doku auf die ich verweise.



Vielen Dank im Voraus, falls sich jemand die Zeit nimmt!

 

[DorMoordor]

Es wäre schon gut, wenn du deine Fragen und was du gemacht hast mit Responses auch hier noch mit rein packen könntest. Denn wenn irgendwann jemand über diesen Thread stolpert ist es nicht unbedingt gegeben, dass der Comdirect Thread noch erreichbar ist.

@Topic kannst du noch posten, was du wann an den Server gesendet hast und die dazugehörige Response. Dabei aber auch die SessionID (solltest du vom Server bekommen) und das Authentication Token leicht abändern. Die benötigt man nämlich, um die API zu nutzen. Sind zwar nur 10 Min gültig, aber sicher ist sicher

 

[panapple]

Stimmt, das ist ein guter Einwand!

Hier der Beitrag den ich Forum von Comdirect gepostet habe:

Danach eine Übersicht meiner requests und responses.

Beitrag Comdirect Community Forum:
"
Meine momentane Situation:

Ich habe die Doku Schritt für Schritt verfolgt und bin in dem OAuth2-Verfahren soweit gekommen, dass ich nach Schritt 2.5 "CD Secondary Flow" ein "200 OK" bekomme.
Leider bekomme ich bei allen weiteren Anfragen an "ACCOUNT" ein "403 Forbidden" zurück und ich weiß nicht wieso.

Frage 1: "Abruf Session-Status"
So wie ich es verstehe geht es in Schritt 2.2 darum ein Session-Objekt für alle weiteren Schritte anzufordern.
Ist Schritt 2.2 auch dafür da um zu ermitteln, ob die TAN-Authentifizierung bereits erfolgt ist?
Kann man diesen Schritt auch im späteren Verlauf wiederholen, um dem Programm die Möglichkeit zu geben, zu ermitteln, ob die TAN bereits vom Nutzer freigeben wurde?


Frage 1.1: "Abruf Session-Status"
In der Beschreibung zum Session-Objekt steht, dass "activated2FA" angibt, ob eine 2-Faktor-Authentifizierung vorliegt.
Bedeutet "true" in diesem Fall, dass das Verfahren 2-Faktor-Authentifizierung im Allgemeinen vorliegt ,unabhängig von der Freigabe, oder ob die 2-Faktor-Authentifizierung erfolgreich durchgeführt wurde?


Frage 2: "sessionId"
Im Beispiel-Header bei Punkt 2.2 "Abruf Session-Status" ist angegeben, dass die "sessionId" diesem Wert entspricht: "123_beliebige_ID_fuer_Session_12".
Im Moment erzeuge ich für die "sessionId" eine zufällige zehn-stellige Nummer und für die requestId eine sieben-stellige.
Soll der Nutzer zufällige "sessionIds" und "requestIds" generieren? Wenn ja, wie lang sollen diese sein?


Frage 2.1: "sessionId"
In der Angabe zum Path bei Punkt 2.3 "Anlage Validierung einer Session-Tan" ist angeben dass eine "sessionId" benötigt wird.
Bei der Beschreibung dieser "sessionId" ist angeben, dass es sich um den "identifier" aus dem Session-Objekt handelt.
In der Beschreibung des Session-Objekts unter 2.2.1 ist angegeben, dass der "identifier" die UUID der Session und nicht meine zufällig generierte "sessionId" ist.
Im Weiteren steht in jedem Beispiel zur "x-http-request-info" sowie in jedem Beispiel zum Body bei "sessionId" die Angabe "123_beliebige_ID_fuer_Session_12".
Wann verwendet man die von mir generierte "sessionId" und wann die von Comdirect erzeugte UUID?


Frage 3: "Aktivierung einer Session-Tan"
In meiner photoTan-App bekomme ich nach Schritt 2.3 "Anlage Validierung einer Session-TAN" einen Auftrag zur Tan-Freigabe auf meine Photo-Tan-App auf meinem Handy geschickt.
Im Header der Response nach Schritt 2.3 konnte ich nachvollziehen, dass es sich dabei um das Verfahren "P_TAN_PUSH" handelt.
In der Beschreibung zum Response-Header unter 2.3 steht bei "challenge", dass im Falle von P_TAN_PUSH die challenge entfällt.
Heißt das, dass ich Punkt 2.4 "Aktivierung einer Session-TAN" auslassen kann?
Wenn ich Schritt 2.4 auslasse, bekomme ich nach Schritt 2.5 "CD Secondary Flow" kein "200 OK" mehr sondern ein "400 Bad Request".


Frage 3.1: "Aktivierung einer Session-Tan"
Wenn ich Schritt 2.1 bis 2.3 ausführe, das Programm kurz warten lasse um meine Photo-Tan zu authentifizieren und dann Schritt 2.4 und Schritt 2.5 ausführe bekomme ich jeweils ein "200 OK".
Wenn ich Schritt 2.1 bis 2.4 direkt hintereinander ausführe bekomme ich nach 2.4 ein "400 Bad Request".
Wenn ich Schritt 2.1 bis 2.3 ausführe, das Programm kurz warten lasse um meine Photo-Tan zu authentifizieren, 2.4 auslasse, und dann Schritt 2.5 ausführe, bekomme ich ein "400 Bad Request"
Wozu dient Punkt 2.4 "Aktivierung einer Session-Tan" genau? Geht es darum die Tan zu authentifizieren? Oder geht es darum die Tan nach der Authentifizierung zu aktivieren? Wenn ja, warum ist das notwendig?


Frage 4: Ist Schritt 2.5 "CD Secondary Flow" optional?
Ich möchte lediglich meine Konto und Umsatzdaten von "ACCOUNTS" abfragen und benötige keinen Zugriff auf Banking- oder Brokerage-Schnittstellen.

"
Ende Beitrag Comdirect Community Forum

Übersicht Requests und Responses:

In diesem Fall habe ich Schritt 2.1 bis 2.3 direkt hintereinander ausgeführt, das Programm 10 Sekunden warten lassen, während ich die TAN freigebe, und dann Schritt 2.4, 2.5 und schließlich die eigentliche Anfrage Schritt 4.1.1 ausgeführt.

Schritt 2.1: OAuth2 Authentifikations-Token erzeugen
Request:

• Methode: POST
• URI: https://api.comdirect.de/oauth/token
• Header1: Accept; application/json
• Header2: Content-Type; application/x-www-form-urlencoded
• Body: password=<replaced_for_privacy>&grant_type=password&client_secret=<replaced_for_privacy>&client_id=<replaced_for_privacy>&username=<replaced_for_privacy>

Response:

• Status-Code: 200
• Headers:

java.net.http.HttpHeaders@2ba7792e { {cache-control=[no-store], connection=[close], content-language=[en-US], content-type=[application/json;charset=UTF-8], date=[Mon, 24 Oct 2022 20:53:33 GMT], referrer-policy=[strict-origin-when-cross-origin], server=[nginx], set-cookie=[qSession=24172093.b8e9ce76ee1d20052749279; domain=.comdirect.de; path=/; secure], strict-transport-security=[max-age=31536000; includeSubDomains], vary=[Accept-Encoding, Accept-Encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers], x-content-type-options=[nosniff], x-frame-options=[sameorigin], x-xss-protection=[1; mode=block]} }

• Body:

{
"access_token": "bf40e103-4f9f-4d84-8c82-1088a9927097",
"refresh_token": "d09a5a9c-2499-4c07-9284-a18f7b27e6ad",
"scope": "TWO_FACTOR",
"bpid": 10528203,
"token_type": "bearer",
"expires_in": 599,
"kontaktId": "<replaced_for_privacy>",
"kdnr": "<replaced_for_privacy>"
}

Schritt 2.2: Abruf Session-Status
Request:

• Methode: GET
• URI: https://api.comdirect.de/api/session/clients/<clientID_replaced_for_privacy>/v1/sessions
• Header1: Accept; application/json
• Header2: Authorization; Bearer bf40e103-4f9f-4d84-8c82-1088a9927097
• Header3: x-http-request-info; {"clientRequestId":{"requestId":"5105825","sessionId":"4074136069"}}
• Header4: Content-Type; application/json
• Body: no body

Response:

• Status-Code: 200
• Headers:

java.net.http.HttpHeaders@6c1442b { {cache-control=[no-cache, no-store, max-age=0], connection=[close], content-language=[en-US], content-type=[application/json;charset=UTF-8], date=[Mon, 24 Oct 2022 20:53:33 GMT], referrer-policy=[strict-origin-when-cross-origin], server=[nginx], set-cookie=[qSession=24172093.4074136069:c747e70af6de; domain=.comdirect.de; path=/; secure], strict-transport-security=[max-age=31536000; includeSubDomains], vary=[Accept-Encoding, Accept-Encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers], x-content-type-options=[nosniff], x-frame-options=[sameorigin], x-xss-protection=[1; mode=block]} }

• Body:

{
"identifier": "87459139FE1E4BF78DB5BB209707357D",
"sessionTanActive": false,
"activated2FA": false
}

Schritt 2.3: Anlage Validierung einer Session-TAN
Request:

• Methode: POST
• URI: https://api.comdirect.de/api/session/clients/<clientID_replaced_for_privacy>/v1/sessions/4074136069/validate
• Header1: Accept; application/json
• Header2: Authorization; Bearer bf40e103-4f9f-4d84-8c82-1088a9927097
• Header3: x-http-request-info; {"clientRequestId":{"requestId":"5105825","sessionId":"4074136069"}}
• Header4: Content-Type; application/json
• Body:

{
"identifier": "87459139FE1E4BF78DB5BB209707357D",
"sessionTanActive": true,
"activated2FA": true
}

Response:

• Status-Code: 201
• Headers:

java.net.http.HttpHeaders@514cfba9 { {cache-control=[no-cache, no-store, max-age=0], connection=[close], content-language=[en-US], content-type=[application/json;charset=UTF-8], date=[Mon, 24 Oct 2022 20:53:33 GMT], referrer-policy=[strict-origin-when-cross-origin], server=[nginx], set-cookie=[qSession=24172093.4074136069:0faf4c551225; domain=.comdirect.de; path=/; secure], strict-transport-security=[max-age=31536000; includeSubDomains], vary=[Origin, Access-Control-Request-Method, Access-Control-Request-Headers], x-content-type-options=[nosniff], x-frame-options=[sameorigin], x-once-authentication-info=[{"id":"225818042","typ":"P_TAN_PUSH","availableTypes":["P_TAN_PUSH","P_TAN","P_TAN_APP"],"link":{"href":"/api/session/v1/authentications/C9A4B36C23D94C44A8BDEDC56B7B8D90","rel":"related","method":"GET","type":"application/json"}}], x-xss-protection=[1; mode=block]} }

• Body:

{
"identifier": "87459139FE1E4BF78DB5BB209707357D",
"sessionTanActive": true,
"activated2FA": true
}

Programm 10 Sekunden pausiert, während ich auf meinem Handy in der PhotoTan-App die TAN authentifiziere

Schritt 2.4: Aktivierung einer Session-TAN
Request:

• Methode: PATCH
• URI: https://api.comdirect.de/api/session/clients/<clientID_replaced_for_privacy>/v1/sessions/4074136069
• Header1: Accept; application/json
• Header2: Authorization; Bearer bf40e103-4f9f-4d84-8c82-1088a9927097
• Header3: x-http-request-info; {"clientRequestId":{"requestId":"5105825","sessionId":"4074136069"}}
• Header4: Content-Type; application/json
• Header5: x-once-authentication-info; {"id":"225818042"}
• Body:

{
"identifier": "4074136069",
"sessionTanActive": true,
"activated2FA": true
}

Response:

• Status-Code: 200
• Headers:

[Server: nginx, Date: Mon, 24 Oct 2022 20:53:43 GMT, Content-Type: application/json;charset=UTF-8, Connection: close, Vary: Accept-Encoding, Vary: Origin, Vary: Access-Control-Request-Method, Vary: Access-Control-Request-Headers, X-Content-Type-Options: nosniff, Cache-Control: no-cache, no-store, max-age=0, Referrer-Policy: strict-origin-when-cross-origin, Strict-Transport-Security: max-age=31536000; includeSubDomains, X-Frame-Options: sameorigin, X-XSS-Protection: 1; mode=block, Content-Language: en-US, set-cookie: qSession=24172093.4074136069:0f18f048af4a; domain=.comdirect.de; path=/; secure]

• Body:

{
"identifier": "87459139FE1E4BF78DB5BB209707357D",
"sessionTanActive": true,
"activated2FA": true
}

Schritt 2.5: CD Secondary Flow
Request:

• Methode: POST
• URI: https://api.comdirect.de/oauth/token
• Header1: Accept; application/json
• Header2: Content-Type; application/x-www-form-urlencoded
• Body: grant_type=cd_secondary&client_secret=<clientSecret_replaced_for_privacy>&client_id=<clientID_replaced_for_privacy>&token=bf40e103-4f9f-4d84-8c82-1088a9927097

Response:

• Status-Code: 200
• Headers:

java.net.http.HttpHeaders@96aafdc { {cache-control=[no-store], connection=[close], content-language=[en-US], content-type=[application/json;charset=UTF-8], date=[Mon, 24 Oct 2022 20:53:44 GMT], referrer-policy=[strict-origin-when-cross-origin], server=[nginx], set-cookie=[qSession=24172093.78840d133d004fd63354ade; domain=.comdirect.de; path=/; secure], strict-transport-security=[max-age=31536000; includeSubDomains], vary=[Accept-Encoding, Accept-Encoding, Origin, Access-Control-Request-Method, Access-Control-Request-Headers], x-content-type-options=[nosniff], x-frame-options=[sameorigin], x-xss-protection=[1; mode=block]} }

• Body:

{
"access_token": "7c09e2db-dc6b-4881-8536-aa084a244130",
"refresh_token": "4f88b8cd-2069-4515-9403-3e67c8299bb8",
"scope": "BANKING_RW BROKERAGE_RW MESSAGES_RO REPORTS_RO SESSION_RW",
"bpid": 10528203,
"token_type": "bearer",
"expires_in": 599,
"kontaktId": <kontaktId_replaced_for_privacy>,
"kdnr": "<kdnr_replaced_for_privacy>"
}

Schritt 4.1.1: Abruf AccountBalances alle Konten
Request:

• Methode: GET
• URI: https://api.comdirect.de/api/banking/v2/accounts/<clientID_replaced_for_privacy>/balances
• Header1: Accept; application/json
• Header2: Authorization; Bearer bf40e103-4f9f-4d84-8c82-1088a9927097
• Header3: x-http-request-info; {"clientRequestId":{"requestId":"5105825","sessionId":"4074136069"}}
• Header4: Content-Type; application/json
• Body: no body

Response:

• Status-Code: 403
• Headers:

java.net.http.HttpHeaders@1539ea71 { {cache-control=[no-cache, no-store, max-age=0], connection=[keep-alive], content-language=[en-US], content-length=[0], content-type=[*/*;charset=UTF-8], date=[Mon, 24 Oct 2022 20:53:44 GMT], referrer-policy=[strict-origin-when-cross-origin], server=[nginx], strict-transport-security=[max-age=31536000; includeSubDomains], vary=[Origin, Access-Control-Request-Method, Access-Control-Request-Headers], x-content-type-options=[nosniff], x-frame-options=[sameorigin], x-xss-protection=[1; mode=block]} }

• Body: no body

 

[DorMoordor]

Soll der Nutzer zufällige "sessionIds" und "requestIds" generieren? Wenn ja, wie lang sollen diese sein?

Also normalerweise solltest du die als response auf einen deiner ersten Requests erhalten und nicht selber erstellen. So kenne ich das zumindest.

Schritt 4.1.1: Abruf AccountBalances alle Konten
Request:

• Methode: GET
• URI: https://api.comdirect.de/api/banking/v2/accounts/<clientID_replaced_for_privacy>/balances
• Header1: Accept; application/json
• Header2: Authorization; Bearer bf40e103-4f9f-4d84-8c82-1088a9927097
• Header3: x-http-request-info; {"clientRequestId":{"requestId":"5105825","sessionId":"4074136069"}}
• Header4: Content-Type; application/json
• Body: no body

Nutzt du hier das Bearer Token aus 2.5 (hier access_token in der Response genannt)? Oder etwas anderes? Weil in deinem Beispiel sind die unterschiedlich.

 

[panapple]

Nutzt du hier das Bearer Token aus 2.5 (hier access_token in der Response genannt)? Oder etwas anderes? Weil in deinem Beispiel sind die unterschiedlich.

Ich habe bis eben immer den gleichen benutzt, der in Schritt 1 erzeugt wurde, da mir nicht klar war, dass Schritt 2.5 einen neuen Token erzeugt.
Daran muss es gelegen haben, da ich jetzt Zugriff auf alle weiteren Anfragen habe. Danke schonmal!

Also normalerweise solltest du die als response auf einen deiner ersten Requests erhalten und nicht selber erstellen. So kenne ich das zumindest.

Hierzu habe ich in der Doku eine genauere Erklärung gefunden (unter Punkt 1.2.2). Anscheinend soll man tatsächlich eigene Ids generieren.
Was ich trotzdem ziemlich verwirrend finde, ist das manchmal die von Comdirect generierte UUID gemeint ist, wenn von der "sessionId" geredet wird, und manchmal die eigens generierte "sessionId".
Ich verwende jetzt einfach in der URI immer die UUID, weil dort speziell auf den "identifier" im Session-Objekt hingewiesen wird, welcher die UUID meint. Und überall sonst meine generierte "sessionId", das scheint zumindest zu funktionieren.

Fragen die mir bleiben:
Frage 1: Abruf TAN-Status
Im Moment lasse ich mein Programm manuell zehn Sekunden warten, während ich die TAN freigebe. Ich möchte aber eher einbauen, dass das Programm nachfragt, wie der Stand der Freigabe ist und nach der nächsten erfolgreichen Prüfung des Status fortfährt.
Der einzige request der für mich Sinn ergeben würde ist Schritt 2.2 "Abruf Session-Status", da dort in der Response ein Session-Objekt mit den Angaben {"sessionTanActive":"Boolean"} und {"activated2FA":"Boolean"} ist. Das klingt für mich am ehesten danach, ob die Tan freigegeben wurde oder nicht, wobei ich nicht genau weiß was was bedeuten soll.
Leider bekomme ich auf diesen request bei beiden Feldern immer ein "false" unabhängig davon, ob ich die TAN vorher freigeben habe oder nicht.
Wie kann ich mein Programm prüfen lassen, in welchem Zustand sich die TAN-Freigabe befindet?

Frage 2: Ist Schritt 2.5 "CD Secondary Flow" optional?
Ich möchte lediglich meine Konto und Umsatzdaten von "ACCOUNTS" abfragen und benötige keinen Zugriff auf Banking- oder Brokerage-Schnittstellen.



Schonmal vielen Dank für die Hilfe bis hierher!

 

[DorMoordor]

Frage 1: Abruf TAN-Status

Wie gibst du denn aktuell die TAN frei? Wenn ich das richtig verstehe, kannst du mit 2.4 die TAN über dein Programm senden, dann könntest du eine Eingabe machen, die einfach so lange wartet, bis du die TAN eingegeben hast und Enter oder so gedrückt hast.

st Schritt 2.5 "CD Secondary Flow" optional?

Sieht so aus. Kannst es ja erstmal weg lassen und schauen,wie weit du kommst

 

[panapple]

Ich gebe die TAN über die PhotoTAN App auf meinem Handy mit dem PhotoTAN-push frei. Dadurch ist leider keine Kommunikation mit dem Programm auf meinem Rechner möglich, außer über die gegebenen requests.

Schritt 2.2 "Abruf Session-Status" gibt komischerweise die Info zurück, ob die TAN aktiv ist oder nicht. Aber leider erst nachdem man die TAN freigeben und Schritt 2.4 "Aktivierung einer Session-TAN" durchgeführt hat.
Diesen Schritt kann man aber erst durchführen, wenn die TAN-Freigabe durchgeführt wurde, weil die TAN-challenge sonst abgebrochen wird.
Das heißt um zu prüfen ob die TAN freigegeben wurde muss man wissen ob die TAN freigeben wurde.

Ich hatte noch die Idee, mein Programm auf eine manuelle Eingabe warten zu lassen, die der Nutzer macht, sobald er die TAN freigeben hat.
Das würde funktionieren, finde ich aber ziemlich unschön.

Übersehe ich etwas, oder gibt es keine Möglichkeit das Problem algorithmisch zu lösen?

 

[DorMoordor]

Ich würde es für den Anfang mit manueller Eingabe machen. Einfach um es erstmal zum Laufen zu bekommen. Feinheiten kann man immer noch verbessern.
Ich kenne mich mit der API der Comdirect leider zu wenig aus, um dir weiter zu helfen

 

[andy_m4]

Dadurch ist leider keine Kommunikation mit dem Programm auf meinem Rechner möglich

Und das ist "by design" so. Es soll ausdrücklich zwischen Rechner und Handy (oder was auch immer der zweite Faktor ist) keine Verbindung geben. Weil das eben ein Sicherheitsrisiko wäre.
Wenn man daran jetzt versucht irgendwie dran vorbei zu basteln (was ja möglich wäre), dann untergräbt man genau diesen Sicherheitsgedanken. Darüber sollte man sich klar sein, bevor man sowas in Erwägung zieht.

 

[panapple]

Ich würde es für den Anfang mit manueller Eingabe machen. Einfach um es erstmal zum Laufen zu bekommen. Feinheiten kann man immer noch verbessern.
Ich kenne mich mit der API der Comdirect leider zu wenig aus, um dir weiter zu helfen

Danke trotzdem nochmal! Mit deiner Hilfe bin ich schon ein großes Stück weiter gekommen.

Und das ist "by design" so. Es soll ausdrücklich zwischen Rechner und Handy (oder was auch immer der zweite Faktor ist) keine Verbindung geben. Weil das eben ein Sicherheitsrisiko wäre.
Wenn man daran jetzt versucht irgendwie dran vorbei zu basteln (was ja möglich wäre), dann untergräbt man genau diesen Sicherheitsgedanken. Darüber sollte man sich klar sein, bevor man sowas in Erwägung zieht.

Das macht Sinn.
Kennst du die mit der OAuth2 Implementation von Comdirect aus?
Hast du eine Idee, wie man das Verfahren automatisieren kann? Also wie das Programm prüfen kann, ob die TAN freigegeben wurde oder nicht?

 

[andy_m4]

Dazu kann ich leider nix sagen.

 

[sandreas]

Hast du eine Idee, wie man das Verfahren automatisieren kann? Also wie das Programm prüfen kann, ob die TAN freigegeben wurde oder nicht?

Du kannst den Session-Status abrufen

 

[SheepShaver]

Ohne, dass ich jetzt die API-Doku genau studiert haette. Du hast den OAuth2-Flow schon durchlaufen und hast Access und Refresh Token? Mit dem Access Token kannst du dann die MFA-Endpoints aufrufen.

Zu deinen Fragen:
activated2FA besagt, ob MFA-Authentifizierung fuer den Account aktiviert wurde oder nicht, es sagt nichts ueber den Zustand aus.

GET URL-Präfix/session/clients/{clientId}/v1/sessions gibt dir den identifier der Session zurueck, den nutzt du zum anfordern und validieren des 2nd Factors.
Die Werte fuer den x-http-request-info Header erzeugst du im Client. SessionID erzeugst du pro Session, RequestID pro Request. Diese SessionID hat nichts mit der serverseitigen SessionID zu tun.

Um auf irgendwelche manuellen EIngaben zu verzichten pollst du
/session/clients/{clientId}/v1/sessions/{sessionId}/validate
einmal pro Sekunde, bis der 2nd Faktor validiert wurde. Wenn der 2nd Faktor nach einer Minute noch immer nicht validiert wurde, dann abbrechen.

 

[panapple]

Ich habe mittlerweile die Lösung gefunden:

Als Antwort auf Schritt 2.3 gibt es einen Header "x-once-authentication-info".
Dieser Header beinhaltet unter anderem das Objekt "link".
Dieses Objekt beinhaltet unter dem Key "href" eine spezielle URI mit der sich der Status der TAN-Challenge abfragen lässt.

Das ganze hat es noch nicht in die Doku geschafft deshalb hier die Details:

• Methode: GET
• URI: https://api.comdirect.de + URI Suffix aus Header (/api/session/v1/authentications/<authenticationId>)
• Header1: Accept; application/json
• Header2: Authorization; "Bearer <access_token>"
• Header3: x-http-request-info; wie bei den vorherigen requests auch
• Header4: contentType; "application/json"

Die Antwort sieht dann so aus:
Status-Code: 200
Headers:
* ganz viele unwichtige Headers *
Body:
{
"authenticationId": "<authenticationId>",
"status": "PENDING"
}

oder

{
"authenticationId": "<authenticationId>",
"status": "AUTHENTICATED"
}

 

[panapple]

Du kannst den Session-Status abrufen

Wenn du damit Schritt 2.2 "Abruf Session-Status" meinst, funktioniert das leider nicht.

Ohne, dass ich jetzt die API-Doku genau studiert haette. Du hast den OAuth2-Flow schon durchlaufen und hast Access und Refresh Token? Mit dem Access Token kannst du dann die MFA-Endpoints aufrufen.

Zu deinen Fragen:
activated2FA besagt, ob MFA-Authentifizierung fuer den Account aktiviert wurde oder nicht, es sagt nichts ueber den Zustand aus.

GET URL-Präfix/session/clients/{clientId}/v1/sessions gibt dir den identifier der Session zurueck, den nutzt du zum anfordern und validieren des 2nd Factors.
Die Werte fuer den x-http-request-info Header erzeugst du im Client. SessionID erzeugst du pro Session, RequestID pro Request. Diese SessionID hat nichts mit der serverseitigen SessionID zu tun.

Um auf irgendwelche manuellen EIngaben zu verzichten pollst du
/session/clients/{clientId}/v1/sessions/{sessionId}/validate
einmal pro Sekunde, bis der 2nd Faktor validiert wurde. Wenn der 2nd Faktor nach einer Minute noch immer nicht validiert wurde, dann abbrechen.

Danke dafür, das mit der Serverseite und der Clientseite macht das ganze klarer. Das geht in der Doku leider etwas unter.