Issue with custom group management in Sanity SSO login

Has anyone here successfully done 3rd-party SSO login with custom group management in Sanity?
We've gotten this all working -- groups are created with grants, users are added to the groups on login, and we do the tokenized claim to generate a Sanity session.

It works with one big problem, studio content is not editable. Every change is rejected with

.
I'll post more detail in the thread.

I've tried tokenizing the Sanity claim using both

administrator

and

editor

, which are the only two options according to the docs.
Our custom groups are called

'admin'

and

'editor'

. Here's what the

admin

one looks like:

Note the full permissions. At least the way I'm reading the docs,

"path": "*",

is supposed to grant access to everything? Or do I need additional filters to make it work?

BTW shout out to -- I used the Community Studio project as a reference point in how I wrote mine, which has gotten me really far! Let me know if you can think of any gotchas that might be causing this issue, thanks!

And for the 3rd-party-auth-example/

Hi Do you have custom access control activated on your plan? SSO is usually an enterprise feature that needs to be activated before you get access to the

create

permission

yes, Enterprise

Cool thanks !

Gotcha. Thanks. I think the doc that threw me off was https://www.sanity.io/docs/access-control#group-documents-c661fcf2c86c — path: *“**” is so commonly used to mean “anything” in the world at large that I assumed it did here as well.

Sorry I didn't get back to you with more general info, but for the most part we followed the several example apps out there including the Community Studio project on Github, and followed the Sanity docs, to achieve Sanity login after we did 3rd-party SSO authorization. In our case we are using Vercel as our host, which has built-in serverless api routes, so I have sanity's login config direct to our /api/login route which makes the SSO call and provides a second route as the handler. I was able to successfully leverage the nextjs-auth0 library to do this serverside without needing to include nextjs as a peer dep. Auth0 is meanwhile working on upgrading their libs to be a bit more generic and avoid the confusion of needing to use something labeled 'nextjs' when really it works fine with just Vercel.