The behavior you’re experiencing is the expected one, more specifically, the fragment component of an URL is never sent by the browsers to the underlying web server.
The underlying authentication protocol (OAuth2/OIDC) specifies a response_type parameter that allows the client application to state what type of response it wants to process. This response type maps to the concept of an authorization grant as specified in OAuth2. There are a few other authorization grants, but the ones most relevant for web application use are:
-
the implicit grant - by default, the success response will contain the requested tokens and is returned as part of the URL fragment component. It’s meant to be used by browser-based applications (think SPA’s) that have their logic running on the client-side and as such can access the fragment component of the redirect URL response.
-
the authorization code grant - by default, the success response will contain an authorization code and is returned as part of the URL query component. It’s meant to be used by regular server-side web application that have their logic run on the web server and as such can maintain a client secret used during the exchange of the received code by the actual tokens.
If your application is a regular web application you may consider switching to the authorization code grant which would return the code in the query component that would indeed be sent to the server-side logic associated with the specified redirect URL.
Additionally, you can also influence the default behavior and for example indicate that you want to perform an implicit grant, but prefer to receive the response using an HTTP POST to the redirect URL instead of the response being included in the fragment component of an HTTP redirect. This is accomplished using the response_mode OAuth2 parameter; for reference information on this check: OAuth 2.0 Authorization Framework