When an OAuth client presents an access token for validation, PingFederate (as an
OAuth authorization server) checks the expiration and the other aspects of the
access token. If the validation fails, PingFederate returns an
invalid_grant
error to the client.
When PingFederate authentication sessions are enabled, you can optionally configure
the access token validation process to evaluate the authentication sessions of the
users (the resource owners) before returning the validation results to the clients.
Depending on the feature (or features) selected on the Session
Validation screen, PingFederate may return to the client an
invalid_grant
error if the associated authentication session
has timed out (or expired), is not found, or has been revoked. Moreover, you may
also configure PingFederate to extend the authentication sessions upon successful
validations.
When any of the session validation features is enabled, the associated session identifier (pi.sri) becomes available through the access tokens. For reference-style access tokens, PingFederate returns the associated session identifier in the response if the access token is valid. For JWT-based access tokens, the session identifier is part of the access token. With the session identifier, an OAuth client may contact the Session Revocation API endpoint to query the status of an authentication session or to revoke an authentication session.
In essence, the session validation features enable you to conjoin the validity of access tokens and the authentication sessions of the users. Because each feature can be independently enabled or disabled per access token management (ATM) instance, you can fully customize unique API and web SSO experiences for your OAuth clients and thus the users.
Once any of the session validation features is enabled for an ATM instance, clients
will not be able to obtain an access token through that ATM instance by presenting a
refresh token. Any attempt will result in an unsupported_grant_type
error. The reason being is that such action, if allowed, defeats the purpose of tying
the validity of access tokens and the authentication sessions of the users in the
first place. Hence, it follows that the Session Validation
features are most suitable for clients using the Implicit
grant type because they do not use refresh tokens. That said, clients using the
Authorization Code grant type can still take advantage of
session validation as needed; they just will not be able to use refresh tokens to
obtain access tokens through the ATM instances that have the session validation
features enabled.