3rd Party SSO Login with Custom Group Management

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

Insufficient permissions; permission "create" required

.
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

Hi ! The path

*

actually only refers to documents with no prefixed path, ie

abcdef

, so the path

**

will also include

drafts.abcdef

. When you try to edit or create a new document in the Studio, whats actually being created is a draft

This is a little unintuitive, so I understand your confusion 🙂 Path expressions are defined here
https://www.sanity.io/docs/ids
The gotcha is, again, that creating a new document means a

draft.

prefiix, which wont match

*

, and the solution should be to change it to

**

for the path value in your grant

Cool thanks !

Np. Suggest looking into the

filter

property instead of

path

if you need more fine grained control over grants. You can achieve the same with
for example, but also add any other groq filter in there (except reference joins

->

)

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.

I can definitely empathize with that, and I’ll bring this feedback to the docs team! Thank you Moses, and hope you get your access control under control 🙂

,We've gone much of the same path as you and solved many of the same problems around granting access. We haven't gotten to the SSO part yet, though, so if you have anything to share with the experience you have now, it would be great.

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.

Thank you for this! 🙂