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?
Thanks
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!
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
