Handling Expired Sessions during Authentication
In many environments there is a need to gracefully bootstrap the user authentication to reset the flow and start from the beginning. A common use case is when a user has bookmarked the login page and at some later point use the bookmark to re-authenticate. In such cases there might not be a session established with the authorization server and this could result in a
400 Bad Request response from the authentication service.
Instead of the user getting a
400 Bad Request message it is possible to have the Curity Identity Server leverage an Application URL. This URL is configurable per client or service provider and is a URL that the server would redirect to if the parameters sent in the request to the server are not enough to initiate the authentication. As in the bookmarked login page scenario where there is no session available.
When the Curity Identity Server redirects to the defined Application URL the original query parameters will be sent on the query string. The application that implements the logic of how this bootstrap should happen needs to use these parameters to appropriately handle the bootstrapping, i.e., how the new OAuth request to the Curity Identity Server should be made. Example:
The Application URL can be enabled on a per client or per service provider basis.
In the OAuth case, navigate to Profile → Token Service → Client → Client Application Settings section → Advanced and set Application URL. Ex.
This URL also needs to be whitelisted in the Authentication service.
Navigate to Profile → Authentication Service → General → Redirect URL Whitelist. Add the same
Application URL that was added to the client and then add
* at the end. Ex.
Only called when no session exists
Note that the App URL will only be called in the scenario where no session exists. The Curity Identity Server does not need a specific flag or parameter in order to call the App URL, it will happen if the App URL is configured and there is no existing session. If the given URL is called by the Curity Identity Server, the client-side application that implements the logic of what happens when that URL is called should assume that there is no session and that the login needs to be bootstrapped.
Below is a very simple Python app that demonstrates the use of the Application URL. As described previously in this article the Curity Identity Server has been configured to redirect to
http://localhost:5000/bootstrap (line 43) if no session is available or if the request cannot otherwise be processed.
This demo app clears the stored token(s), picks up the arguments needed to bootstrap the login (line 51-54) and redirects to the page that will trigger authentication again (line 56) and will make sure that the Authentication starts fresh from the beginning.