Feature Request: Add session renewal or an iFrame AuthorizationRequestHandler implementation.

Right now, if my token provider only gives out short lived tokens (e.g. 5 minutes), I’d have to initiate a new redirect flow every time I want to renew the token to keep the user session alive. This forces me to break the user’s experience and redirect/reload my app every 5 minutes! Ideally, there’d be a mechanism I could use to renew the token without initiating a redirect flow, which is all that seems to be provided from this library. I should note that I’m coming at this from the context of a SPA for which I know RFC 8252 doesn’t directly apply (a SPA is not a native app, but both are public clients!) but know this library is designed to work with SPAs and even has a React example.

I guess I’d like clarification on how I can keep the user session alive without having to perform a redirect flow every time I need to refresh the session. I have coded my own implementation of an iFrame provider that implements the AuthorizationRequestHandler class to shoehorn this functionality into this library, but think it belong here to allow the use of prompt=none background/hidden refreshes for tokens where my OpenID Provider/iDP are aware of a user’s session and consent status. Alternatively, could you provide an example of how we could keep a session alive with the current features provided by this library? Does implementing the OpenID Connect Session Management Draft make sense for this library?

Side note: Google still recommends using the implicit flow for SPAs, and in fact, you cannot use a PKCE exchange with Google on a SPA (though your comments for other issues seem to show that Google knows better!) Is this something you can clarify or maybe have addressed internally at Google?

[brockallen]

Is this something you can clarify or maybe have addressed internally at Google?

And once they’ve done that, I encourage them to lead the charge at the spec committee making changes and recommendations there as well. I’d love to see a formal explanation of how code flow makes security better for SPAs. Up to now, that has not been shown.

[brockallen]

Is this “iFrame handler” defined in an OAuth spec? If not, then it’s likely out of scope for AppAuth.

OAuth2 does not preclude it, and OIDC specifically adds prompt=none to formalize it.

Conceptually the way SPAs behave feels more like a native app than a web site (no shared cookie state, no URL bar), and the code flow is required for native apps…

Implicit is designed to limit the ability to renew access tokens to the user’s browser session. Code flow leads to refresh tokens, which allows for renewing access tokens beyond that browser session (given that it’s a public client). This is the main “pandora’s box” security concern for code flow in the browser, IMO. I’d love for the spec committees to get involved with addressing this. I posted a few months ago to the list on this exact topic.

What’s not clear is why code flow is superior from a security standpoint for a browser-base client. I’ve seen the arguments, and they all revolve around developer convenience and how the iframe approaches don’t feel so modern.