Configure OKTA to make a POST request instead of GET request while doing a sign_in on enduser dashboard

When end user visits Sign In and click on the app icon a GET request is made to http://localhost:3000/users/auth/okta/callback?code=something.

Currently I receive this message

I would like to make this request to be a POST instead of a GET, what should I do?


This guide from Omniauth provides a recommendation. Based on this, it sounds like the POST limitation is specifically related to /auth/:provider:

If the use of GET requests to /auth/:provider is essential for your application (for example, if you are ever redirecting to /auth/:provider as part of an authentication process), then you will need to put together a more involved solution for your specific needs. This may mean redirecting to a standard log-in screen which includes link_to ‘Log in’, ‘/auth/:provider’, method: :post or another POST/form-based approach (like button_to).

How I read this is that you can make another route in the application to redirect the user back to (from the Okta dashboard via OIDC Compliant IdP-initiated login flow) and that route can then post to /auth/:provider to start the login flow app-side.

You might want to read up more about the ways others have resolved this CVE in Omniauth, as this doesn’t look to be an Okta-specific issue

Hi @andrea , thanks for answering.
Let’s check if I understood.

Are you suggesting to instead of having a Sign-in redirect URI as my “real callback endpoint” that really sign_in the user, I should set a Sign-in redirect URI to a “proxy callback endpoint” that does the post request to my “real callback endpoint”?

I thought OKTA would have a way of just doing a POST request instead of a GET request to my Sign-in redirect URIs, OKTA does not support that? Does this mean that every OKTA customer has to develop it own approach for this?

I’ve read the posts about the ways others have resolved this CVE in Omniauth. The fix is to do POST instead of GET requests for sigin buttons/links they have in the application. But in this case, as I am sigining in through a button from OKTAs dashboard I cannot set it to be a POST instead of a GET. So in my understanding it is a OKTA-specific issue.

I was suggesting updating the “Initiate Login URI” on the Okta side. That’s the one that Okta is redirecting the user to when they launch the app from their dashboard via the app tile. You’ll want to set this to a URI in your application that is not /auth/:provider, and have your application make the POST to /auth/:provider instead of having to find a compatible way to get Okta to do the POST instead.

Hi @andrea thanks for the clarification, it is clear to me now!

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.