React to .NET Core 3 to OKTA issue

Hi guys/girls,

My issue is outlined here:

If people for whatever reason cannot hit link, the issue is:

My React application (frontend) (not OKTA- enabled) is requesting data from my .Net Core 3.0 (backend) web API (is OKTA- enabled). When requesting a protected endpoint from my frontend app, I am getting a CORS error: ( some data ‘xx’-omitted for privacy)

“Access to XMLHttpRequest at ‘’ (redirected from ‘https://localhost:44300/api/project/all’) from origin ‘http://localhost:44350’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”

I believe this is simply because I am calling the protected endpoint via a React API REST call, as typing “https://localhost:44300/api/project/all” into the browser triggers the redirect to login and then returns the correct data fine.

Is there a way I can have my React app call “API.get(https://localhost:44300/api/project/all)” and that hit my backend, redirect to login on react app, and then once user logs in, return data from API as normal to React app from API backend?

I fear I may need to implement frontend OKTA auth too but I would like to avoid this if possible?

Any thoughts?

Also, my redirect and trusted origins are set up correctly as required:

If you know that you will be talking to your protected backend, why do you need that complicated redirect scenario? Can you obtain the access_token for your backend, when user hits your frontend? Your worst fears are real :slight_smile: you need to implement login to Okta from your frontend. If you are too lazy you can just do redirect to Okta login page :slight_smile:

Ya that’s what I feared. I spent ages back and forth with the team in charge of OKTA integrations in my company for my backend. Now it looks like I will have to reimplement it all on the frontend again. It is very surprising that protected endpoints on a backend application block any non-okta-enabled frontend app from using it…

lol, it’s funny, but it’s true, as it’s the whole purpose of protecting your backends :slight_smile: so that whoever does not have access_token, is prohibited to use your protected backend. Protection works!

And APIs (backends) usually just simple microservices which do not have to carry a burden of helping to obtain the access_token.

Ah, I worded last comment the wrong way lol. What I meant to say was, it is surprising that you can’t OKTA-protect a backend and have a frontend simply pull the token from the backend. Instead of protecting a backend and then realising you need to protect frontend in the exact same manner making the backend protection pretty much a waste of time except for URL protection from people directly accessing API.

It is kinda obvious that a protected backend is not query-able by any frontend, but when a user tries to access a backend via a frontend to be redirected to login, and then continue from there, that is the suprising part. OKTA does not allow unauthenticated frontends to even redirect to a login page and then to a resource through a backend.

Well, i guess it’s something you can suggest as an idea on their page as an improvement for their .net library

I think it is just because I created the Web API first, so I am working backwards to the frontend when I should be instead passing the token from the frontend to backend. Thanks for help anyways man :slight_smile:

1 Like

Should not be a big deal to inject protected routes, I guess. Though I have no idea how difficult it is in React :slight_smile: good luck, anyway!

Hi @clawlor

You can use the postMessage() method in order to request tokens from Okta, instead of doing a CORS redirect and hitting the browser block. You can find here a vanilla JavaScript example for this use-case.