The company uses SAML 2.0 and okta for a lot of things and I was told that I have to, if I can, make my ReactJS app use SAML 2.0.
Please, you ask me okta support, or anyone else I have no choice in the matter and I’m not allowed to use OIDC, even though I know that is the recommended way to secure SPA.
My ReactJS is only a client, there is no server side code running, period.
The app makes maybe ten to twenty different API calls.
From what I’ve seen I need to have both a server setup to integrate SAML 2.0, but is this 100% correct?
I can’t spin up any type of web server at all, again my company has rules/limitations.
Is it possible to use something like passport saml passport-okta-oauth with only ReactJS and nothing else?
By the way, I was able to get ReactJS to work with OIDC, found an example and went from there. This configuration does not require a server to be created.
Hi there @peteletkemanrakuten !
Yes, you’ll need a server-side component for SAML support.
As for passport-okta-oauth, I’m not sure Passport works for browser-based applications as it’s built for Node.js.
I understand you have some constraints to work within, so this suggestion may not be possible, but one option might be bootstrap your React app within a web app context (such as how it’s scaffolded in this SpringBoot+React tutorial). I wish I had better news for you.
Let us know if you need anything else.
@alisaduncan is correct, generally you need a server component. I thought I would respond as well, to explain the reason is the identity server will send the SAML assertion on a redirect message to the ACS, the assertion consumer service URL. So the user’s browser will reach out to the server on the redirect and pass the assertion to it.
But… SAML supports two forms of redirect: POST and “redirect” which is a GET. POST sends the XML assertion as form data, but “redirect” sends it as data on the URL line, URL encoded of course. Typically it is in the query string as the “SAMLResponse” attribute. If you make Okta use the “redirect” format the data should be visible to the SPA once it loads, if it checks it’s own URL. You are going to have to do a bunch of work to attempt this. Nobody I know of has a library or NPM package that will help you do this. And, the assertion size is limited by the constraints of the query string.
So… if your server ignores the query string when the user’s browser lands there and returns the SPA correctly you can:
- Configure Okta to use the SPA landing URL as the ACS (also known as the service provider login URL).
- Have the application redirect the user to the identity provider login URL (Okta sets that) to initiate the login. Of course if the user is already logged into the Okta organization SSO kicks in.
- Have the application look for the assertion in the query string when it loads, if it is there it knows who the user is. Of course you really need to check the digital signature, the identity provider entity id, and the audience in the assertion data
Disclaimer: of course Okta supports none of this hack to get the assertion to the SPA!