Async token refresh (Token Rotation) - 7PT

[schefbi]

Das Token soll neu asynchron refreshed werden. Somit haben wir kein redirect mehr. Ausserdem wird mit dieser Erweiterung auch ein Sicherheit eingebaut.

Dokumentation SLH: https://clx-evento.bitbucket.io/EVT2023.R2_eventodoc/Api/Autorisierung/RefreshToken/#refresh-uber-token-endpunkt-asynchron

POST - /Authorization/{InstanceId}/Token
Body kann entweder als Content-Type: application/json oder | application/x-www-form-urlencoded übergeben werden. 
{
    refresh_token: {RefreshToken},
    grant_type: "refresh_token",
    client_id: {ClientId},
    culture_info: {Culture}
}

ToDos:

• [ ] Access Token soll über einen Timer asynchron refreshed werden.
• [ ] Ein Sprachwechsel kann auch über den /Token Endpunkt gemacht werden. Hierzu ist zu beachten das diese für alle Scopes gemacht wird. Die der Benutzende aktiv hat.
• [ ] Wenn erstmalig der Scope des Access Token gewechselt werden muss. Muss das über den /Login Endpunkt gemacht werden. Wenn die App für den Scope bereits ein Refresh Token hat. Kann das Refreshen über den asynch POST /Token Endpunkt gemacht werden.
• [ ] Wegen der implementierten Token Rotation gibt es pro Scope einen Refresh/Access Token Strang. Diese müssen pro Scope im localStorage abgelegt werden.
• [ ] Anpassung in software-architecture-documentation-sad

[schefbi]

@hupf Ich habe es einmal Beschrieben was alles gemacht werden muss. Wir werden am Freitag 12.01.2024 den Release auf Test integrieren. Ab Montag sollte dann die Version mit der asynch token refresh (Token Rotation) vorhanden sein. Ihr könnt euch das einmal anschauen dann meldet Ihr euch einfach.

[hupf]

@schefbi Danke für die Spezifikation. Sind folgende Aussagen also korrekt (damit wir uns richtig verstehen):

• Über den neuen POST-Endpunkt kann ich mit einem Refresh-Token eines beliebigen Scopes ein Access- (bzw. Refresh-Token) eines anderen Scopes holen.
• Aufgrund der Token-Rotation werden die bisherigen Access- und Refresh-Tokens bei einem Refresh revoked. D.h. unser Caching-Mechanismus, wo wir uns pro Scope die Access-Tokens merken, funktioniert nicht mehr. In Zukunft werden wir uns nur noch ein Access-Token merken können und bei jedem Scope-Wechsel ein neues holen müssen.
• Für die Substitution müssen wir nichts spezielles berücksichtigen – diese können wir auch über den neuen POST-Endpunkt erneuern.

Bezüglich der Umsetzung heisst das für uns konkret:

• Für das Access-Token Renewal, statt dem Redirect neu den POST-Endpunkt verwenden über XHR.
• Das Redirect zum Login bei Ablauf des Refresh-Tokens bleibt so bestehen wie es ist.
• Der Timer-Mechanismus zum Erneuern des Access-Tokens bei Ablauf bleibt so bestehen wie er ist (nur gibt neu den XHR-Request anstelle des Redirects).
• Sicherstellen, dass die App (bzw. das iframe) erst gerendered wird, wenn das neue Token geladen und persistiert wurde. → Braucht ev. einen neuen State; möglicherweise Spinner anzeigen...
• Den "Pro Scope" Caching-Mechanismus aus- bzw. umbauen → nur noch das letzte Access-Token merken im localStorage.
• Die Überprüfung bei der Navigation ob das Access Token halb abgelaufen ist macht auch nicht mehr Sinn, da wir stets ein neues Access Token asynchron holen können – auch während die App aktiv ist. Bei der Navigation reicht neu eine Überprüfung ob das Access-Token grundsätzlich noch gültig ist.
• Dokumentation anpassen.

[hupf]

Mit der aktuellen Implementation der Token Rotation werden die Access-Tokens der anderen Scopes invalid, sobald man den Scope wechselt, dies führt dazu, dass beim Öffnen eines neuen Tabs oder Fensters die bisherigen Tabs/Fenster nicht mehr authentifiziert sind.

Deshalb ist diese Issue im Moment "On Hold", bis es eine Lösung gibt (z.B. Access-Token gar nur pro Scope oder gar nicht rotieren bzw. Scope Handling komplett überarbeiten).

[hupf]

Mögliche Zwischenlösung mit separaten "Token-Strängen" pro Scope:

• Pro Scope ein eigenes Refresh-/Access-Token Paar im localStorage pflegen.
• Beim 1. Wechsel auf einen anderen Scope (oder wenn das Refresh-Token für den anderen Scope abgelaufen ist) wird ein Login-Flow durchgeführt und ein neues/separates Refresh-Token für diesen Scope geholt.
• Beim asynchronen Erneuern eines Access-Tokens wird das jeweilige Refresh-Token des betroffenen Scopes verwendet. Mit der Token Revocation wird dabei das alte Refresh- und Access-Token Paar invalidiert. Die Tokens der anderen Scopes sind aber weiterhin gültig, da es sich um einen eigenen "Strang" handelt (verifizieren ob das wirklich so ist, sonst bräuchte es einen Change bei SLH).
• Die OAuth-Loginseite soll bei bereits gültiger Session direkt zurückredirecten, damit der User bei einem Scope-Wechsel nicht noch einmal einloggen muss. Hier ist ein Change auf Seite SLH nötig.
• Bei einem POST auf /Logout sollte die Session beim OAuth-Provider gelöscht werden. Hier ist ein Change auf Seite SLH nötig.

Vorteil dieser Lösung:

• Wir können die Tokens asynchron refreshen.
• Wechselt man innerhalb des gleichen Scopes, oder zu einem Scope den man schon verwendet hat, bleibt die App bestehen und es kann ein gecachtes Token verwendet werden.

Nachteil dieser Lösung:

• Bei jedem Wechsel auf einen Scope auf dem man noch nicht war, findet ein Redirect statt und die App wird neu aufgebaut (Flickering).
• Etwas mehr Komplexität beim Token-Refresh.
• Wenn man den User oder Mandant wechseln möchte (kommt das in der Praxis vor?) müsste man zuerst ausloggen und dann wieder einloggen (wo hätte die Session auf dem OAuth-Provider noch eine Auswirkung?).

[hupf]

@schefbi Können wir noch folgende Punkte verifizieren:

• Kann man ein Access Token von einem bestimmten Scope refreshen, ohne dass durch die Token Rotation Refresh/Access Tokens von anderen Scopes invalidiert werden?
• Kann per Redirect ein Login-Flow gemacht werden (um ein zweites Refresh Token für einen anderen Scope zu holen), ohne dass Refresh/Access Tokens von anderen Scopes invalidiert werden?
• Kann die OAuth-Loginseite bei bestehender Session direkt zurückredirecten, ohne dass Users sich erneut anmelden müssen (für das Szenario im vorherigen Punkt). → dies müsste umgesetzt sein, wenn wir mit der Implementation beginnen.

[schefbi]

@hupf Dieser Change ist noch nicht umgesetzt bei SLH. Wir haben auch noch kein Datum. Falls es nicht reicht wenn ihr das Projekt startet werden wir ihn verschieben. Alle deine Punkt werden in diesem Change umgesetzt.

[hupf]

Update:

Aktuell ist ein neuer Endpunkt für einen asynchronen Login geplant, mit dem über XHR ein Token mit einem anderen Scope gefetched werden kann. Damit wird dann folgendes Vorgehen möglich werden:

1. Gültiges Access Token für den gewünschten Scope vorhanden → verwenden :+1:
2. Access Token für den gewünschten Scope abgelaufen, Refresh Token noch gültig → neues Refresh/Access Token Paar über den async Token Endpunkt (POST /Authorization/{instance_id}/Token) fetchen
3. Kein Refresh Token für gewünschten Scope vorhanden oder abgelaufen → Refresh/Access Token Paar über den async Login (POST /Authorization/{instance_id}/Auth) fetchen
4. 401 vom async Login oder kein Refresh Token vorhanden → Redirect zum Login

Dabei gibt es zwei Timers:

• Bei Ablauf eines Access Tokens → Erneuern über async Token Endpunkt
• Bei Ablauf eines Refresh Tokens → Erneuern über async Login Endpunkt oder bei 401 Redirect zum Login