Unerwünschtes automatisches Logout aus der SAC-App

[sync-by-unito]

Ausgangslage

Meldungen von Fabian, dass gewisse Mitglieder sich immer wieder neu in die SAC-App einloggen müssen.

“Wenn ich von der App her kommen einlogge, möchte ich “ewig” eingeloggt bleiben. Darum soll der default für das Flag “"angemeldet bleiben" für Logins von der App “aktiviert” sein.”

Anforderung/ Analyse

Analyse wieso die App-Benutzer ausgeloggt werden & Definition einer möglichen Lösung

• Hitobito: [~accountid:557058:11e2b0c3-cf79-4b0c-b867-b671a359f0b1] Bewirkt das Flag “angemeldet bleiben” auf der OIDC-Loginmaske für die aktuelle Konfiguration für die SAC-App OIDC Client ID überhaupt was?
• SAC-APP: [~accountid:5ff2c0fbb66825010e977770] siehst du da etwas in den Logs? Werden viele regelmässig aus der App ausgeloggt?

┆Issue is synchronized with this Jira Task by Unito
┆Issue Number: HIT-961

[sync-by-unito]

➤ Mike Wong commented:

Andreas Gurtner In der Android App loggen wir das Event, wenn eine Session Expiration (invalid_grant Antwort vom IDP, siehe https://datatracker.ietf.org/doc/html/rfc6749#section-5.2 ( https://datatracker.ietf.org/doc/html/rfc6749#section-5.2|smart-link ) ) passiert. Ich sehe hier auf Sentry 6354 relevante Events (auf Android) in den letzten 30 Tagen.

Bei der invalid_grant Exception sehe ich zwei Fehlermeldungen (eine von WSO2 und eine von Hitobito:

• WSO2: Persisted access token data not found Diese Meldung erscheint in 1842 Events
• Hitobito: Die bereitgestellte Autorisierung ist ungültig, abgelaufen, widerrufen, mit einem anderen Client verknüpft oder der Weiterleitungs-URI stimmt nicht mit der Autorisierungsanfrage überein. Diese Meldung erscheint in 4512 Events

Dieses Issue war bereits in der alten App bekannt und tritt auf wenn die App ein Token Refresh anfragt, dieser Request beim Server ankommt aber die Antwort (also das neue Token) nicht bei der App ankommt. Der Server hat dadurch das alte Token bereits invalidiert, die App hat aber das neue nicht erhalten und wird beim nächsten Request wieder das alte mitschicken. Dieses Problem müsste sich mit einer korrekten IDP Konfiguration grösstenteils beheben lassen.

[sync-by-unito]

➤ Andreas Gurtner commented:

Hoi Mike Wong , vielen Dank fürs schnelle Feedback! Dies sind ja doch einige Fälle... Die WSO2 Einträge ignorieren wir mal, da dies sowieso der auslaufende Strang ist. Bezüglich Hitobito habe ich kurz mit Andreas Maierhofer geschaut, er analysieren und behebt das Problem.

[sync-by-unito]

➤ Andreas Gurtner commented:

Hoi Andreas Maierhofer , hier noch zwei Beispiele von Personen die regelmässig aus der App-Ausgeloggt werden: https://portal.sac-cas.ch/de/groups/6800/people/231537 ( https://portal.sac-cas.ch/de/groups/6800/people/231537 ) und https://portal.sac-cas.ch/de/groups/6874/people/443851 ( https://portal.sac-cas.ch/de/groups/6874/people/443851 )

[amaierhofer]

Ich habe das lokal ausprobiert und folgendes Verhalten beobachtet.

1. Token Refresh selbst invalidiert das bestehenden Access Token nicht. Sofern nicht epxired kann das Access Token weiterhin verwendet werden.
2. Erst die Verwendung des beim Refresh erhaltenen neuen Access Token invalidiert das alte Access Token.

Soweit ich das beobachtet habe, muss der Client also das neue Token verwendet haben, damit das alte Token invalidiert wird.

Können wir ein Timing issue in der App ausschliessen? Aktuell haben wir +2000ms antwortzeiten auf Prod für token requests. Kommt vielleicht die Antwort vom Refresh "zu spät" beim Client an?

[sync-by-unito]

➤ Mike Wong commented:

Andreas Maierhofer Danke für deine lokalen Tests. Das sieht nach einem für mich korrekten und sinnvollen Verhalten aus.

Timing Issues kann es bei der App immer geben. Angenommen ich habe langsames Internet (schlechte Verbindung, VPN, etc.), dann kann die App einen Token Refresh Request machen, der beim Backend ankommt, aber die Antwort vom Server erreicht die App nicht weil der Request dazwischen in ein Timeout reinläuft. Das können wir nicht umgehen, ausser wir würden Timeouts generell ausschalten, was dafür andere Probleme mit sich bringen würde.

Gemäss deiner Beobachtung müsste das allerdings kein Problem darstellen, da die App beim nächsten Mal einfach erneut einen Token Refresh versuchen würde. Sofern der IDP dabei das Refresh Token (du schreibst nur vom Access Token) weiterhin akzeptiert, würde das dann zu einem Erfolg führen. Das erklärt für mich dann nicht die Fehlermeldung, die wir von Hitobito erhalten.

Wie verhält sich der IDP wenn ich mehrere Sessions besitze und mich in einer davon auslogge (z.B. im Browser). Werden nur die Tokens von dieser Session invalidiert oder alle mit dem User verknüpften Tokens?