IUA Refresh token handling

[oliveregger]

Refresh token handling needs to be defined if allowed or not (refresh without authentication possible).

[msmock]

We won't allow refresh token, since their lifetime management is quite difficult.

[oliveregger]

we are waiting currently on feedback from trifork or @unixoid

[limux82]

Proposal for Using Refresh Tokens in ITI-71

Since ITI-71 is derived from the OAuth2 flow, we believe that it should adhere to the secure mechanisms provided by the standard, specifically the refresh token mechanism for obtaining new access tokens.

The decision to prohibit the use of refresh tokens for IUA tokens has significant practical implications for both web applications and mobile apps:

1. Loss of Application State in Web Applications

Redirecting the browser to the Authorization Server for a new authentication session each time the IUA token expires can lead to a loss of application state.

• In JavaScript-based frontend applications, where active state (e.g., form data, user selections, in-memory data) is maintained, a forced redirection causes frustration and disrupts the user experience.

2. User Experience Impact

• Mobile Applications: Opening an external browser for authentication is impractical and highly disruptive.
• Web Applications: Redirecting the user to the Authorization Server and then back to the application breaks the user flow. Additionally, the page state must be reloaded, which can cause delays, especially on low-bandwidth connections.

3. Benefits and Security of Refresh Tokens

• Refresh tokens provide a secure and standardized method to obtain new access tokens without disrupting the user flow.
• Rotating refresh tokens significantly reduce security risks:
  • Each refresh token is valid only once, minimizing the impact of potential token leaks.
  • The lifetime of the refresh token can be generally configured in the Authorization Server, aligning it with the session duration.
  • A maximum duration for the refresh token can be defined to further control security.

Conclusion

Prohibiting refresh tokens unnecessarily complicates the authentication flow for both end users and developers.

We propose a reevaluation of this decision, considering additional security measures such as:

✅ Rotating refresh tokens – ensuring security while maintaining a seamless user experience.
🔗 OAuth 2.1 Refresh Token Endpoint Extension

✅ PKCE (Proof Key for Code Exchange) in the Authorization Code grant – increasing protection against attacks.
🔗 RFC 7636 - PKCE

By adopting these security enhancements, we can achieve both security and usability without sacrificing user experience.

[jkiddo]

FYI @oliveregger @msmock - @limux82 represents the 'Trifork' case here.

[msmock]

An IUA authorization server may not create an new authorization token, without verifying the user has a running session with
the identity provider. Currently annex 8 does not allow refresh token. The identity provider involved in the discussion agreed upon not to add the refresh token due to security problems. We currently see no way to fulfill the requirement to validate the users IDP session other than to enforce re-authentication via the client browser.

But even if we had a OpenID Connect refresh token, the implementation would be cumbersome. If the IUA authorization server uses a refresh token via the backchannel the session information on the authorization server and browser cookie gets out of synch.

The recommendation in the literature is to avoid useability problems with (hidden) IFrames. Is that impractical from your point of view?

[limux82]

Yes, it is impractical. Silent authentication is highly discouraged: modern browsers block silent authentication using iframes due to tightened security measures (such as SameSite policies and third-party cookie restrictions). This method is unreliable, and mobile apps cannot support it at all since you simply cannot have an iframe in a mobile app. For this reason, many OIDC vendors recommend using PKCE along with rotating refresh tokens.
That said, the refresh token mechanism remains essential between the client and the authorization service. Regarding verifying that the IDP session is still active, most IDPs currently support SAML and offer a defined SAML renew action. We can feasibly perform a SAML renew with the IDP at the moment of the OIDC token refresh between the Authorization Client and Authorization Server. This approach ensures that the IDP session remains active. Moreover, ITI‑71 should permit the connection between the Authorization Server and the IDP to also use SAML (see GitHub Issue #258), allowing us to maintain only OIDC between the Authorization Client and Server (in this way we don't have impact on SmartOnFhir).
Additionally, several market solutions exist that can update cookies during token refresh, ensuring that cookies remain in sync with the new tokens.