So I've read this page, and I've tried all the extra parameters you can pass, but they don't seem to work like I thought they would.
So when my app redirects to the Genesys login screen, my process is currently:
Choose "more login options"
Enter my org name
Press the "Microsoft" button that appears on the next page
Now even with org=&provider=adfs&target=, I still have to go through this whole riggamaroll to authenticate. Not a big deal for me in dev, but it would be nice if users didn't have to do that. So I've been re-reading the docs, and found that the "target" docs say this:
"When intending to log in to a specific target organization using Authorized Organizations, providing this value will skip the org selection screen after authentication and will automatically complete the log in process for the specified target org."
So apparently these are for after a user enters a username/password. That's kinda nice and all, but that's obviously not what I'm looking for. Is there any way to tell that first screen what the org are and what "other login options" are available? No biggy if not, just hoping to make things a bit easier on users.
EDIT: I'm also curious about the "state" parameter; I tried setting it to an "arbitrary URL-encoded value" as the docs suggest, but that caused a "too many redirects" error (lol). How exactly is that supposed to work? Maybe that's what I'm looking for?
No, you cannot pre-populate the org. The "other login options" items are not controllable by you; they are determined based on the org the user chooses.
The state parameter is an arbitrary value that's not processed by the login server; it's just sent back to you in the redirect to your app. It shouldn't have anything to the redirect process. You'll need to troubleshoot the redirect issue using your browser's developer tools to identify what's causing it.
Well that's a bummer (I forgot to write step 4 = then enter your e-mail lol). A 4-stepper is a bit of a pain, but not unbearably so. Users will just have to deal I guess. Unless there's some other way to do a single sign-on (never used "SAML" before but I'm guessing maybe?).
But getting back to "state", I'm pretty sure the too many redirects was unrelated - I was just setting up the OAuth basics at the time, so I'm not concerned about that anymore. But thanks for explaining that it's totally unrelated to logging in (kinda surprised the docs don't say that lol... or maybe they do in a more subtle way than "totally unrelated" and I misread it ).
I don't mean to sound rude or anything, but what would be the point of "state" then? What I mean is, what would it be used for? It can be passed with the login stuff, but it's unrelated to logging in... does some other API call need it? I haven't ran into a case where I've needed it yet, so I'm just a bit confused by it being there at all (in the auth docs of all places).
Using the SAML2 Bearer grant is the only way to get around the user having to use the Genesys Cloud login screen. You're still at the mercy of whatever the SAML provider does to authenticate the user, but at least Genesys Cloud won't show anything during that flow.
State is typically used by web apps so that the web app can relate the app's state before the redirect to login with the response after the login. This can mean anything because it's fully dependent on how you code your app to send a value and what it does with a state value it receives.
One of the most common use cases for this is to work around the fact that OAuth requires a static callback URL for your app. So maybe your user went to myapp.com/page/two but didn't have an auth token already so the app had to initiate a login flow. It could pass /page/two as a URI encoded value in the state so that when the flow sends the user back to myapp.com/callback, the app handles the new token, reads the state, and knows to redirect the user back to the page they wanted to view before being redirected. This use case is used by the dev center when adding an account; it's how you get back to the same page you were on before adding the account.
Not to throw the book at you, but we have the state param because it's part of the OAuth RFC. Here's a little light reading if you care for a deep dive. RFC 6749: The OAuth 2.0 Authorization Framework
No worries! We're all too familiar with dense specs around here (WCAG, ARIA, etc.) so I totally understand when u have to add stuff because {compliance}. OAuth is not one we've had to delve too deep into until very recently, so it's good to know the spec requires it. But more importantly, thank you for taking the time to explain the use case. Also glad to know the SAML thing is my route for single sign-on. What I'm building is for internal use, so I'd rather jump thru the hoops myself than ask users to. Anyway, thanks again and have a good one.
).