如何确定用户是否仍在使用 PingFederate OpenID Connect 隐式客户端流程登录？

Question

鉴于用户使用隐式客户端流登录到我的应用程序的场景，其中 OP 是 PingFederate，我如何确定用户是否仍然登录，如果他们关闭了应用程序并在有效的时间内返回到它时间段？

Answer 1

Resurrecting an old question since OpenID Connect is still widely used. To check if a user is authenticated--either from a previous session with your app, or from a session with another federated application--supply prompt=none in the authentication request. Per the spec , the documentation on prompt=none states:

The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required, or another code defined in Section 3.1.2.6. This can be used as a method to check for existing authentication and/or consent .

"Silent Authentication" uses this prompt=none parameter inside an iFrame. Auth0 has some discussion on it, here . In a nutshell, the authentication request is made in an invisible iFrame so that the user agent's main frame is not redirected. Depending on your identity provider (IdP), this may or may not be a valid option. For security reasons, authorization endpoints often deny requests made in frames using the X-Frame-Options: DENY header. Cookie origin policies on the IdP may also prevent silent authentication. That said, the same can be accomplished with eg a popup or a full User Agent redirect on initial load of the SPA.

It's worth pointing out that the Implicit Flow has been deprecated for a long time due to a wide range of security issues, many of which do not have sufficient mitigation strategies. The OAuth 2.0 for Browser-Based Apps describes current best practices. Nowadays the Code Flow with PKCE can be used, but it still has a number of security issues that cannot be sufficiently mitigated (again described in the best practices doc).

Code Flow with a back-end session server in an edge device (a server between your SPA and API server) is the best bet security wise. This approach keeps tokens out of the User Agent altogether, helping to mitigate token leaks through XSS attacks, and if done correctly, CSRF attacks become impotent. Pertaining to the question, a long-lived refresh token can be stored in the session server, and can be used to persist authentication across page refreshes or closing the browser. Here is a write-up on this approach.

Addressing one of the comments above: "Why would a user that closes a website after completing authN expect the AuthN to still be valid after that closure?" Because it's better user experience, and expected user experience nowadays. Think about Google, Atlassian, or even this very site (StackOverflow): A user logs in once and pretty much never has to log in again, provided that user interacts with the site frequently and doesn't raise any security red-flags.

Addressing another comment: "If you got to the point of where the application now has an 'ID Token', that's the key. For as long as the token is valid (check expiry time)." Both ID Tokens and Access Tokens should expire quickly, while Refresh Tokens should be long-lived. This way, if the IdP revokes access for a user, the revocation will quickly propagate to all Client applications.