Ich sitze gerade an einem Projekt, bei dem ich externe Daten in unser internes System einpflegen muss und bin mir nicht sicher, wie ich die Authentifizierung am besten handhaben soll. Die API des Anbieters nutzt OAuth 2.0, aber ich frage mich, ob ich den Token wirklich bei jedem einzelnen Request mitschicken muss oder ob es eine elegantere Möglichkeit gibt, die Verbindung aufrechtzuerhalten. Manchmal fühlt sich das so redundant an, vor allem wenn viele kleine Abfragen in kurzer Zeit nötig sind. Hat jemand ähnliche Erfahrungen gemacht und weiß, wie man das etwas effizienter gestalten kann?
Ja das kenne ich gut. Immer dieses Token Ping Pong zwischen Client und Anbieter. Wenn viele kleine Abfragen anstehen wirkt es wirklich redundant den Token bei jedem Request mitsenden zu müssen und trotzdem up to date zu bleiben.
Aus technischer Sicht lohnt sich oft ein Token Cache mit Hintergrund Refresh. Man hält den Access Token kurz lebendig im Service und holt neue Tokens über den Refresh Token statt bei jedem Aufruf neu zu verhandeln. So bleibt der Fluss stabil und die Belastung durch Authentifizierung sinkt.
Ich dachte man müsse wirklich jeden Aufruf mit einem frischen Token zeigen und eine dauerhafte Verbindung gibt es nicht. Vielleicht hat sich hier eine falsche Erwartung festgesetzt.
Ich bin skeptisch ob der ganze Token Trick wirklich der richtige Weg ist. Vielleicht steckt das Problem eher in der Infrastruktur oder im Gateway Design statt in der Token Logik und OAuth 2.0 wird zur Nebensache.
Vielleicht geht es um eine andere Perspektive als Token Verwaltung. Ein Proxy der Tokens erneuert und Anfragen bündelt könnte die Lösung sein oder man arbeitet mit Batch Abfragen um wiederholte Authentisierung zu vermeiden.
Was wäre wenn man statt ständiger Token Verwaltung eine serverseitige Session mit kurzen Lebenszyklen nutzt und die Clients einfach mit einer Session ID arbeiten lassen würden?
