Thanks @TheLumberjack , those are good news. I've upgraded to 1.4.3 and 3.10 of ZAC and was wondering about this new token type field. Tried changing it to ID, but it didn't work. What did you put as Store ID when using the UWP client type?
My Keycloak is still working with this token type ID and ZDEW 2.6.0, but it hangs with the spinning Z after being authenticated from Google when I try to use it to log in ZAC with it. Didn't have time to further investigate, I was going to look into this today.
I tried to add an edit on the post. I was successful at authenticating using our go sdk however I was unsuccessful when using the csdk. Unfortunately the ZDEW uses the csdk. Apparently Google is the first idp we have encountered that adds a slash into the code used when completing the pkce flow and this causes a problem in the csdk. The ZDEW won't be able to login directly with Google until we can fix that. I've identified the issue, we just need to get a release made.
It seemed to be entirely irrelevant. I put in anything.
I didn't try ZAC-based auth but that's a good idea, I was focusing on ZDEW. I'll try that later as well.
Overall, I'm still trying to read all the Google related doc to figure out why this worked for me. I've learned more about why the either client types don't work. Google decided that localhost redirection is invalid even though PKCE should make these worries irrelevant. My current best guess is that the UWP profile exclusively allows for localhost redirects. As you'll notice, there's no field to add in there for valid redirect URLs.
I'm still not entirely satisfied with our stuff working with Google's idp. I'm continuing to try to find a workable solution that doesn't seem goofy. So far, Google's decisions around this aren't really aligning with basically every other idp I've used so far. I am considering providing guidance to our users to federate auth to Google (like via Keycloak, etc) because of the decisions they've made.
I wanted to reply because i didn't want to to keep trying the ZDEW since I've identified the issue in the c sdk preventing it from working.
It's ok, i did the upgrade and the token type specification change, without success, before your post here with the UWP client type workaround attempt. I find it interesting that we're getting back to this localhost redirection problem that started my thread here. Looks like Google had to adapt their workflow to accommodate Microsoft...
The federation with Keycloak works fine and after some testing we came to the conclusion that Google is great for authentication but isn't well suited to control access to applications. Even though it works, the groups administration in Google workspace isn't really built to manage that kind of thing. So, something like Keycloak, Authentik or Okta is needed to manage access with onboarding and offboarding workflows.
My only problem right now with Keycloak is the ZAC login that isn't working with it, even though it's working with the ZDEW. As I understand it, I get a cross-origins error when ZAC tries to get the token from Keycloak. I've tried updating the web origins in Keycloak without success. Still investigating.
I was able to replicate the issue. Looking at dev tools, it had a clear error that keycloak wasn't alloing the CORS request.
Go into your keycloak, open your realm, find your client and scroll down to "Web origins". For my zac, located at https://ctrl.zrok.clint.demo.openziti.org:8441/zac/dashboard, I had to use exactly: https://ctrl.zrok.clint.demo.openziti.org:8441. No trailing slash, no trailing *.
Alternately you could open it wide open with * but it seems like that's not a great idea to me.
Wow, thanks again @TheLumberjack, it was a trailing slash that was blocking the request. I was convinced that a trailing * after the slash would handle everything. These settings are just way too sensitive to this, wasting so much time trying to figure out what should be simple. On the other hand, I should have considered this sooner; you keep warning us about those trailing slashes. Lesson learned!
ZDEW 2.6.2 was released with the fix for Google's IdP. I'm going to recommend to users they federate Google anyway. It's too finicky. I've spent days trying to get Google's OIDC implementation to work "properly". I can't find any magical incantations to get the Google Auth Platform to allow an OIDC flow from anything OTHER than the awkward "Universal Windows Platform (UWP)".
It will work, but it's clunky imo. The ergonomics of federating Google are much better. It also gives you the ability to federate to other providers if you choose then too, Facebook, GitHub etc.
