How will DSSO invoke my web app?

I wrote a NodeJS application that will soon live in an Okta DSSO environment, and I want to play nice with SSO. I’ve been told that I will be able to auto-populate fields based on something I’ll be getting but no one seems technical enough to tell me what to look for.

My SPA is built in NodeJS/Express and the page is the root route (GET https://server/). What will the DSSO-enabled browser send me that I can use to populate fields? Will there be a body in the GET? Does it append a query string? Do I have to respond with a 302 or listen for POST requests?

This is pretty basic wire-level info, but I cannot find anything in the docs or with various people. I can consume anything I need to, I just need to know what I’ll be fed.

Thanks!
Chris

PS: I’ve seen a lot of NPM libs, but they all seem to be overkill for my purpose.

I guess this is a really hard question? I’m surprised there isn’t an easy and well-known response that someone could give me. Are there {okta} folks here? I’m assuming that my app is “the callback redirection” page. What does that mean for me?

OK, I should note I’m trying to avoid the invasive rewrite as described in this developer example! I don’t think I need to become an Okta-enabled player, do I? Can I not just read a token Okta sends me? Going for the simplest solution here.

@NodeDev57 Hi, can I ask what docs you were referring and what is your end goal?
Are you trying to call GET endpoints and verify sth?
Here is a list of node.js examples. You can refer them
https://developer.okta.com/code/nodejs/

Hi Lijia,

I linked the doc I was looking at in my 2nd reply. It’s a node/express example. But is way to invasive for the simple thing I want to accomplish (receive the DSSO invocation of my URL).

My users are using Desktop SSO and my URL is already installed in some Okta admin thingy somewhere. The Okta rep said “so you’ll just get a POST request and you can get the user’s data from that”. I’m wondering how. I want one piece of data they said would be in there. In where? A cookie? The POST body?

I want to make the smallest change possible. Does my app really need to be bound with all the Okta libs or can I just do something simple like var user = req.body.userID;?

Maybe it can look this simple? →

app.post('/', busboy(), function (req, res) {
  if(!req.busboy) {
    res.status(500).send('Missing library');
    return;
  }
  req.busboy.on('field', function(key, value, keyT, valT) {
    if( key == 'userid' ) {
      res.cookie('user',value);
  });
  req.pipe(req.busboy);
});

Chris

@NodeDev57 Hi, you can call POST request in postman to get data first before implement it in code. It will be returned in a response.

The below is a simple sample of Node.js to get user.
You can create a sever and call any API endpoint.

const http = require(‘http’);
const hostname = ‘127.0.0.1’;
const port = 3000;
const server = http.createServer((req, res) => {
res.statusCode = 200;
if (req.url == ‘/getuser’) {
GetUsers()
}
res.end(‘Hello World\n’);
});

const request = require(‘request’);
const baseurl = ‘https://xxx.oktapreview.com
const options = {
headers: {
‘Authorization’: ‘SSWS{{apiKey}}’,
‘Content-Type’: ‘application/json’,
‘Accept’: ‘application/json’,
//‘mode’:‘no-cors’
}
}

function GetUsers() {
options.url = baseurl + ‘/api/v1/users/{{userId}}’
request.get(options, function(error, response, body){
console.error(‘error’, error);
console.log(‘statusCode:’, response && response.statusCode);
console.log(‘body:’, body);
});
}

server.listen(port, hostname, () => {
console.log(Server running at http://${hostname}:${port}/);
});

If you still have any questions or need to chat with someone from our side, you can open a support ticket through an email to support@okta.com. One of our Dev Support Engineers will take the case and help you review.

Hey Chris,

It sounds like you want to use a SWA sign in flow here since your app doesn’t already speak SAML or OIDC (Single Sign-On in applications | Okta)

Ideally you would want your app to use SAML or OIDC since those are secure, open protocols that remove the need for you to do user management locally in your app. If your app spoke SAML or OIDC, the end of each of those protocol flows returns a secure piece of data (an “assertion” in the case of SAML, or a JSON Web Token in the case of OIDC). The best way to add one of these protocols to your app is to use an existing library. Okta has a version that it makes available, but these are open protocols so you can use lots of different libraries or even roll your own. If you do this, you can connect with Okta or any other IDP with minimal effort.

In case you don’t want to overhaul your app as above, then that’s where SWA comes in. Basically SWA is a way to accommodate passing a username + password to your app in whichever method it understands today. SWA can pass credentials to your app via:

  • if the app supports authenticating via a form POST to the specified URL Okta can send a POST that contains the username and password of a user plus any static headers or body info your app expects to receive in its existing login flow today.
  • if your app has an existing login flow which is either username+password and a Submit button, or has username and password on separate pages, or collects username and password in an iframe. Okta can use CSS Selectors you specify to locate the existing fields for username/password/submit button/checkboxes/Next buttons/extra data fields, and then will populate those fields and “click” the buttons on behalf of the user.
  • if your app supports Basic Auth, Okta can pass the data to your app and submit an auth form.

None of these SWA flows require your app to change. At the end of the flow, it looks to your app like a user just logged in the same way a normal user would. So then you just grab user info however you do today.

Thank you both. One thing about my app - it needs no credentials. It’s open, anyone can use it. There’s no passwords. All it does is accept the company’s standard user credential and direct them to another site based on a lookup. If the lookup fails it fails, if it succeeds, then the destination is the one which will need the deep integration with Okta (and that’s under way).

So, yes, I don’t want to handle user management at all, either in my app or bouncing back and forth with Okta. However, if Okta can invoke my URL and pass me something useful, I’m all for making the user’s life easier. I’ll take it and do the redirect and be happy not to maintain a UI anymore!

It was my understanding that between the Desktop SSO (“just log into the PC and you’re good for the day”) and having my URL registered in Okta, I could get a token that would have the userid (and potentially even the lookup data). I think the only way to get that is a POST or a GET with a body or query strings.

I’ll do a deeper dive into both your answers to see if I can understand how/if they’d apply to my situation. Again, thanks so much!

Chris