We are implementing Keycloak as an IDP, and will use it to secure some apps (Relying Parties)
The apps are likely to use something like mod_auth_openidc, which will use the Authorization Code flow to direct the user to keycloak where the user will log in, do the openidc dance, and ultimately end up back at the "redirect_uri".
We will be calling the applications with a set of parameters, lets say for example: https://some-application/launch?person=12345
The redirect_uri is going to be https://some-application/launch, as I understand the Oauth2 spec is quite specific that the redirect_uri should be static, and not contain parameters/be dynamic.
So this means following login the request parameter "person=12345" is lost, as the user is simply redirected back to "https://some-application/launch"
What is the recommended pattern/approach to persist this "person=12345" request parameter before the OIDC dance takes place?
I have read about the "state" parameter, but I am unclear how we would inject anything into this with mod_auth_openidc, or how we would read any values from it? Is it more of an application framework question - would some kind of controller/server side code (PHP/c# etc) somehow store these values in session (but I am unclear if they would have a chance to before mod_auth_openidc kicked in?
It is an application responsibility to store the location before redirecting and to restore it afterwards:
Single Page Apps can manage this via session storage as in this code of mine since they are in control of behaviour before and after
Server Side Web Apps may give you similar options, to store the location in an HTTP only cookie, then restore it after, but you need to check for the particular tech being used. It is a well known usability issue that abrupt redirects may occur that the UI cannot control, and that deep linking (as you described) may not work.
You need an application design to solve this problem. Out of interest my recent blog post mentions this issue.