Single SSO provider for both admin and regular users

[Mazvy]

I may not see the point of this current login/account separation, nor the 2 different login pages for what is just a different user role.

An admin cannot sign in on the public facing page, unless they have 2 accounts created .. on one platform?
So they have to know they need to go to /admin as either I'm blind or can't see from the user facing version (Portal?) anywhere an admin would sign in.
Group assignment only works with the OIDC for /admin - why?

Why can't all users use the same login and admins just have a "Admin area" dropdown when they click their user in the top right - just like 99% of platforms do this.

And if they just need to change a status for an issue - they can do it without having to leave the page that 99% of the other users interact with.

We as a company only use SSO for everything - no usernames or passwords.
In the /admin login I still have to provide an email - why?
If this 1 platform 2 user bases is something that for whatever reason is preferred - why do I still need to enter my email instead of a "Sign in with " button like the users have?

Feature wise this is a great platform.
But dealing with the split user bases for a very admin-unfriendly way of handling the platform is making me look for alternative platforms.
I cannot imagine how I'd need to explain to non tech savvy users this split user base, "hidden" admin, etc.

Oh and also I cannot get admin SSO to work.
SSO flow goes through after entering my admin email (??) to then kick me to the user site (Portal?) with no information other than I can see in the URL bar https://domain/?error=account_not_linked&sort=trending

I've set auto create user and it's not creating one after admin SSO flow.

Edit:

To clarify, I'm looking for a feedback/bug report/suggestion platform for internal company use.
All users use the same OIDC regardless of privileges.
In every other platform this is a non issue, as all user authentication and authorization happen through the same SSO flow.
group mapping takes care of roles.
In turn some members may see more buttons/features/settings than others, but not in a split-user split-management page like we have now.
And furthermore - there is no granularity.
I want to grant certain users to be able to change an issue status - only admins that go through the bizarre login and exposed to too many settings can do this.
So a teamlead has to essentially have the same admin privileges as the system admin in order to change an issue status?

I may be missing something but it seems no consideration was made to the user roles and how they should work.

[mortondev]

Sorry to hear your frustrations @Mazvy, I agree for internal company use (with a single IDP) the UX isn't where it should be and split logins are confusing.

This started out as being aimed at SaaS providers that are collecting ideas from their end customers but I appreciate there's clearly a demand for supporting the use-case of internal company ideas/suggestions too.

I'm going to look at whether it's indeed possible to simply remove the /admin login altogether however there may be other users of Quackback that are using this for end customers with potentially multiple identity providers in use (one for end customers via OIDC and one for employee SSO such as Entra ID). In that scenario it wouldn't make sense to show Entra ID login button since there are two user bases (which is where the triggering SSO by email domain came in).

With all that said I will have a think on how to simplify the overall model and find a compromise that works comfortably for both public and internal use cases.

Edit:
Did you set up SSO and verify a domain? It should work from the portal login based on email matching the verified domain. If it's not please share more details about the identity provider being used etc and I can look into that separately.

[Mazvy]

Sorry to hear your frustrations @Mazvy, I agree for internal company use (with a single IDP) the UX isn't where it should be and split logins are confusing.

This started out as being aimed at SaaS providers that are collecting ideas from their end customers but I appreciate there's clearly a demand for supporting the use-case of internal company ideas/suggestions too.

I'm going to look at whether it's indeed possible to simply remove the /admin login altogether however there may be other users of Quackback that are using this for end customers with potentially multiple identity providers in use (one for end customers via OIDC and one for employee SSO such as Entra ID). In that scenario it wouldn't make sense to show Entra ID login button since there are two user bases (which is where the triggering SSO by email domain came in).

With all that said I will have a think on how to simplify the overall model and find a compromise that works comfortably for both public and internal use cases.

I appreciate your reply, and do apologize if I came off aggressive.

I don't think you need to remove /admin, but it could be better integrated within the portal itself.

In my head you already have it fairly close.

• You could have a "Team-only" mode that has Portal-side initiated SSO with one click login, group mapping, and default to the Portal. Feature wise the building blocks are already there, just merging the Portal and Admin side SSO flows into one.
• Custom Quackback groups, so users can have the ability to just adjust issue statuses, but not roadmap, etc.
• In turn - custom groups for delegating permissions per-category. In a company setting there may be multiple products that need feedback that are all handled by different teams. Having a one-stop-shop for all feedback for employees is great, but an admin nightmare as-is with no granularity.

A lot though would be better with just a non split login flow and ideally non split userbase.
If from the Portal side the single SSO for both admin and users just "dealt with" the split userbase it may be easier to live with.

As-is as I said, the roundabout usability is fairly over-complicated yet at the same time incredibly poor in terms of any form of access management.

Edit:

@mortondev Reply to your edit :D

Here's the settings.
Also I created the SSO provide as a Custom OIDC - but after saving it shows up as Okta.
It still works, as in, triggers the SSO flow and it goes through.
No matter how many times I recreate it as a Custom OIDC after saving and refresh it shows up as Okta.

[mortondev]

A team-only mode of sorts does sound along the right lines for being able to just click login and be immediately redirected.

More granular user controls are coming soon, just hadn't gotten round to it yet (eventually with custom roles but probably presets to begin with - kind of along lines of how GitHub roles work)

I've not directly used Okta before so I'll try and get a free trial and configure it exactly as you have to experience the pain points directly 😬

Probably be Monday when I look into it

[Mazvy]

A team-only mode of sorts does sound along the right lines for being able to just click login and be immediately redirected.

More granular user controls are coming soon, just hadn't gotten round to it yet (eventually with custom roles but probably presets to begin with - kind of along lines of how GitHub roles work)

I've not directly used Okta before so I'll try and get a free trial and configure it exactly as you have to experience the pain points directly 😬

Probably be Monday when I look into it

I am not using Okta.
I'm using custom OAuth/OIDC provider.
The setup for it works in Quackback - the test passes.
But after refreshing the page it then shows up as Okta, even though it was set up as a custom OIDC.

This does not happen on the Portal SSO side - there the same custom OIDC works just fine.
Although there is a bug where if I set the page to be private, the login flow doesn't work.
After the redirect from the OIDC to Quackback - the popup where the SSO happens - the page just shows up as the login page to Quackback "Welcome back. Sign in to keep voting and tracking what <...> ships."

However if I set it to public and clicking the login in the upper right - the SSO flow works just fine.

[mortondev]

Ah okay understood, thanks for the further clarification that makes sense now. On Monday I'll try to get the fix out for private portal flow so it's on par with public at least, and also stopping it showing as Okta incorrectly.

The wider UX issues and permissions will be part of a broader follow up over the coming weeks.

[Mazvy]

Ah okay understood, thanks for the further clarification that makes sense now. On Monday I'll try to get the fix out for private portal flow so it's on par with public at least, and also stopping it showing as Okta incorrectly.

The wider UX issues and permissions will be part of a broader follow up over the coming weeks.

If you are committed to a more private/community/corporate use-case such as how I poorly defined before - I would suggest having an option to instant redirect a user to SSO.

If SSO-only is enforced with no option to manually login - it becomes fairly pointless and not great UX for a user to have to click the "Login" button everytime they visit, at that point just redirect the user to the SSO provider without an unnecessary interaction.

[DereckRadford]

@mortondev would this be an issue since switching to v0.12.4? I had tried accessing the /admin side of things now and I get this error.

[mortondev]

@mortondev would this be an issue since switching to v0.12.4? I had tried accessing the /admin side of things now and I get this error.

In the current model you get that error when accessing /admin and attempt to sign in as a portal user, it shouldn't be different from previous versions.
As discussed further up in the I'm looking at unifying the auth experience along a single surface going forwards which will should remove some of the confusion around this.

[arcdigital]

Having the separate auth is very useful for us. Internal users login via one IDP and customers login via a totally different IDP. The current implementation works perfectly with this use-case.

[DereckRadford]

@mortondev would this be an issue since switching to v0.12.4? I had tried accessing the /admin side of things now and I get this error.

In the current model you get that error when accessing /admin and attempt to sign in as a portal user, it shouldn't be different from previous versions. As discussed further up in the I'm looking at unifying the auth experience along a single surface going forwards which will should remove some of the confusion around this.

So, this is happening for me as an Admin not a portal user. So essentially the site is working now but we can't access the admin interface.

[mortondev]

Having the separate auth is very useful for us. Internal users login via one IDP and customers login via a totally different IDP. The current implementation works perfectly with this use-case.

@arcdigital Rest assured multiple identity providers will still be available, it's only the login page surfaces being reduced and the OIDCs for both end user vs internal users facing will be configured from the same location.

[mortondev]

@mortondev would this be an issue since switching to v0.12.4? I had tried accessing the /admin side of things now and I get this error.

In the current model you get that error when accessing /admin and attempt to sign in as a portal user, it shouldn't be different from previous versions. As discussed further up in the I'm looking at unifying the auth experience along a single surface going forwards which will should remove some of the confusion around this.

So, this is happening for me as an Admin not a portal user. So essentially the site is working now but we can't access the admin interface.

@DereckRadford Could you share any more details about your authentication setup? OIDC providers used, perhaps redacted screenshots of the settings pages etc? You're also welcome to send this information to support@quackback.io if you prefer to not post it here.