Can the user not by pass my custom OIDC IDP login process by reconstructing the Okta callback link?

Questions
1

I am slightly confused as to using my own custom OIDC IDP. Currently, I am using an Authorization Grant with PKCE flow for a Single Page Application. When Okta redirects to my IDP authorize link, it redirects with nonce, state.

Will the user not be able to reconstruct Okta’s callback link with the nonce, state, client_id, redirect_uri, login_hint etc? The redirect_uri will be to the home page of the client, and the rest of the details are not secrets.

What is stopping a malicious user from bypassing my IDP authentication process by reconstructing the log in URL?

Edit:
I am building auth in the following way. Once Okta calls my custom IDP’s /authorize endpoint, I serve a page that requires the user to do something. Only after the user does something successfully to authenticate themselves, then I redirect to Oktas callback URI with the nonce, state, etc. That is where the user is considered logged in.

Edit2:
After some digging and diagramming, I believe the main “secret” is the Authorization Code itself. While the rest of the parameters are public, the Authorization Code links to some data inside my custom IDP server. If the user tries to fake this auth code and “bypass” auth, when Okta tries to exchange the auth code for a token it will fail. Is this understanding correct?

2

You’re correct in your understanding. The authorization code is indeed the key element that prevents bypassing the authentication process. Here’s why:

  1. The authorization code is a short-lived, one-time use token generated by your custom IDP.
  2. It’s linked to specific session data on your IDP server.
  3. When Okta tries to exchange this code for a token, your IDP verifies its validity.
  4. A malicious user can’t fake or bypass this process because:
  • They can’t generate a valid authorization code
  • Even if they intercepted a code, it’s useless without other factors like the PKCE code verifier
  • Attempting to use an invalid or already-used code will fail during the token exchange

So while other parameters (nonce, state, client_id, etc.) are public, the authorization code serves as the crucial, secure link in the authentication chain.

3

Thank you for the affirmation! Definitely figuring things out as I go along. Could you point me to some search terms or topics related to persisting the user session (eg, in browserStorage). I am looking into refresh tokens too!