redirect URIs change Post to Get

I tried to configure a SPA application but found that the Sign-in redirect URIs is actually being POST with a body data id_token.

Is there any way we can set Sign-in redirect URIs as GET with the id_token as url parameter?

The POST vs GET behavior depends on the response_mode parameter that your application sets in the request. For the default with no response_mode set, Okta will redirect back with a GET request and the ID token will be in the query string. If your application sets response_mode=form_post then Okta will cause the browser to make a POST request to your redirect URI.

1 Like

Thank you aaronpk for the quick response!
Might I please ask where we set the response_mode?

That would be a parameter in the initial request, alongside scope and response_type and such. For example:

If you’re using an SDK it should be in the documentation as well.

The default is to use GET, so if you’re seeing a POST, then it means it’s being set somewhere already.

Hi aaronpk,

Please allow me to give you a bit explanation about our scenario. We have a SPA, which we are planning to register in Okta as a application tile. We have our own IdentityServer4 running.

Our customer wants to let their end users to access our SPA through the tile.

Back to your response, in our case, please where should the request we need initiate from? our SPA or our IdentityServer? What the best solution / flow is it supposed to be?

Are you using the Okta Simplified option for your SPA in Okta? From what I understand, that option will always post the id_token to the provided Initiate Login URI configured for the app

Hi andrea,

I just realized that it might be caused by the option that i set.

please see my code snippet.

        services.AddAuthentication().AddOpenIdConnect("okta", "Okta", options => Configuration.Bind("Okta", options));
        services.Configure<OpenIdConnectOptions>("okta", options =>

I have captured the package that it sends to okta, and it indeed contains the form_post parameter as aaronpk mentioned.

question please, how should we set the option to make okta back to us with GET?

hi aaronpk,
what values should i set to get the GET and the token?

i tried with
options.ResponseMode = OpenIdConnectResponseModes.Query;
options.ResponseType = OpenIdConnectResponseTypes.CodeIdToken;

but it said

OpenIdConnectProtocolException: Message contains error: ‘unsupported_response_mode’, error_description: ‘‘query’ response mode cannot be used with either the ‘id_token’ or ‘token’ response types.’, error_uri: ‘error_uri is null’.

any thought please?

Try setting it to Fragment instead of query.

FYI if you use Fragment then you have to look for the ‘#’ in the URL you receive.

I have to ask, why are you not able to use POST? The reason you are having problems with this is that passing the ID token in the URL (query or fragment) is a security risk and therefore the system is making you jump through hoops. Passing the ID token this way will cause it to be recorded in the history of the user’s browser and therefore visible to be decoded at any future time, even if it has expired.

hi jmussman, at my identityserver4 project, i have created a Post endpoint and it can receive the Post request with the id_token body only if i did not set the okta openid auth middleware in the first place, otherwise it ​threw

Exception: OpenIdConnectAuthenticationHandler: message.State is null or empty.

to avoid this exception, i have deleted the auth code so the Post can come in. i am planning to do the auth in controller level, or write some custom middleware to transform the Post to a Get with the id_token to token header so the okta auth middleware can recognize. is that reasonable?

from your experience Mr. jmssman, please what is standard solution to let the Post come in without exception?

here was my code snippet for okta auth middleware registered, which i deleted at the moment:

        services.AddAuthentication().AddOpenIdConnect("okta", "Okta", options => Configuration.Bind("Okta", options));
        services.Configure<OpenIdConnectOptions>("okta", options =>
            options.ResponseType = OpenIdConnectResponseTypes.IdToken;
            options.ClientId = "theCilentId";
            options.Authority = "";
            options.CallbackPath = "/External/CallbackPost";

I’m working a little blind here, I don’t know the real type of “services” in your code. And unfortunately I’m better with Katana than Core. But let’s see if we can work it out together.

First of all, part of the issue is that the middleware you are setting up looks to have been based on getting a response to an Implicit Flow request. I have to wonder if something is expecting a request to have originated from the application, so it is looking for state that it sent out to be returned. So I think we need to figure out how to tell this particular middleware it’s an initiation request with an ID token.

In Katana you can simply disable state validation (because I have exactly the same problem regularly with Authorization Code Flow), but I can’t see how to do that in Core. That doesn’t mean it isn’t there.

Another thing I noticed is that on the first line you bind the the “Okta” section of the configuration, but on the second line you’re setting the “okta” section. Could it be simply a case sensitivity issue and what you set in the second part just isn’t applied?

Here is another idea that may be off the wall: there is a stack overflow question that hints about disabling the Configuration part and just setting up the Authority which could be in line with what I stated might be the issue above. Could you look at this and see if it helps? c# - OpenIdConnectAuthenticationHandler: message.State is null or empty - Stack Overflow

Let me know if anything helped. If not and I can see what exactly what service object you are using maybe I can dig deeper on the Configure extension method for you.


hi @jmussman thank you very much for your response. the “okta” and “Okta” code was borrowed from here IdentityServer4 External Providers - Step-by-Step Tutorial
i just found using okta as external provider is much different from using google. i am afraid i have not found a reliable sample about how to add okta as external provider to an existing identity server 4. :frowning: