Is having the full OpenIddict request in the ReturnUrl for my login page standard practise & secure? .NET 8.0

Question

As the title suggests, I'm implementing an authorization flow into my Angular app/.NET API with PKCE. My angular app will initiate the auth flow, which in-turn directs the user to my login razor page hosted in my API.

To complete the flow after the user's credentials have been validated, the RedirectUrl contains the nessecary information to re-enter the Auth flow as a validated user. which results in my URL for the login page looking something like this.

I have replaced some of the values in an attempt to reduce the size of the URL here.

https://localhost:7208/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%3Fclient_id%3Dtest_client%26redirect_uri%3Dhttp%253A%252F%252Flocalhost%253A4200%252Faccount%252Fauth_callback%26response_type%3Dcode%26scope%3Dopenid%2520profile%2520offline_access%26state%state_value%26code_challenge%full_challenge_code%26code_challenge_method%3DS256%26response_mode%3Dquery

Is this a standard practise for this kind of Auth flow and is it secure?

I have been researching the topic but haven't been able to come to any sort of solid conclusion based on this particular use case.

Answer 1

In short, yes, this is standard for a secure token server (STS). I don't remember if this is OAuth specific or OIDC specific, it's one or the other. To break it down:

1. Your ReturnUrl points to /connect/authorize. This is an authenticated endpoint. This is similar to websites that redirect you to the login page to access it. Once you've logged in, this endpoint processes the user's authenticated state to generate the tokens the client app is requesting. (This is more complicated based on what grant flow you're using)
2. Client ID is passed over as a way for the client to notify the server what application is attempting to authenticate.
3. The redirect URI is the callback url to the client application once the OIDC server has completed it's process. This is OK to have here since the client must provide it's callback AND the server must have it registered as a valid return url in order for it to accept the request.
4. Scopes are the permissions the client is requesting. Sometimes these are listed in the openid-configuration on the server, but these also need to be registered for the application on the server side as well.
5. The remaining parameters are setup for how to challenge the server should be processed.

To summarize, yes, this is all normal. It's as secure as it can be.