I am currently implementing a first version/poc of an OIDC flow for our native .net application. When it comes to the redirect URL, I am currently not sure if I am handling it correctly or if what I am doing might be a potential security risk. What I am currently doing is the following:
My "issue" is with step two. Since we are running a native client the redirect URL the OIDC provider in step two redirects to is just a dummy URL that I created that does absolutely nothing. In the client app I just grab the redirect response from step two, extract the authorization code and continue with the normal flow. No redirection takes place at any point.
This works and I can successfully retrieve a token, but I am wondering if I am opening up the application to security issues somewhere here. For clarity... I obviously also use ClientId, ClientSecret, code challenge and code verifier in my flow. I just omitted them in step 1-3 to make the question clearer. I am happy about any input. Thanks in advance!
You shouldn't be able to do that in the first place. When you send the user to the OIDC provider, that should not be in the context of your native app (like webview or similar), that's kind of the whole point. You should not be able to observe what happens in the user's session with the provider, that should happen in a real browser. When the provider redirects back, in case of native app, the redirect should go to a registered scheme like yourapp:// that your app can then receive because it registered it upon installation.
The reason for this is separation between the identity provider and the resource server (your app). You want to compartmentalize your architecture so that vulnerabilities of one component (eg. the identity provider) do not affect the other (eg. the resource server).
Also in many setups, the identity provider is a public one (like Facebook), and your app uses the identity provided by the IdP. But if I'm logging in to your app, I will not enter my Facebook password in your app, I want to enter it on Facebook. So in these scenarios, the resource server is not even supposed to know the credentials, it just gets the claims from the IdP.
If that is not the case, and in your design you decide this is not a risk (for example because you own both the IdP and the resource server(s) and they are all part of the same application anyway), you don't actually need the authorization code flow, and the whole redirect game is unnecessary. You can just use the resource owner password flow, the user enters the password to your app and it authenticates with that on the IdP. If the user's credentials flow through your app anyway because you use a plain HttpClient to make the request, then this is not actually much worse (if at all) than the authorization code flow, and it is much simpler. (Note that there is still some additional risk compared to a proper, separated IdP, because more components have access to the credentials at some point.)