Clarify purpose of SUPERUSER_GROUP setting in documentation

[AzMoo]

The documentation for how to use the SUPERUSER_GROUP (and potentially STAFF_GROUP) settings could be clearer.

[KoreyPeters]

I appreciate this. :)

As an additional suggestion: would it be possible to map groups in Okta to Groups in Django? For example, my Okta app has several groups configured in Django, and it would be great to just generally know that if I drop a user in the Okta group, the similarly named Django group would have that user added as well. As it stands now, I need to go in to the Django Admin anyway and assign Groups.

[AzMoo]

This is what the MANAGE_GROUPS setting does :)

[KoreyPeters]

lol! Okay. Well. That is all very wonderful. I'll be sure to use that functionality. :)

[samkuehn]

I currently I don't use groups, having trouble getting groups into claims on the Okta side. The problem is that if you do not have groups in claims or have not specified SUPERUSER_GROUP/STAFF_GROUP is_superuser and is_staff gets set to false for every user that logs on. Basically any user logging on loses staff and superuser permissions and cannot access the Django admin. Offending logic:

django-okta-auth/okta_oauth2/tokens.py

Line 107 in 8bfb689

user.is_superuser = bool(

Not sure how you want we want to fix this but a have a few thoughts. Just let Django manage is_superuser/ is_staff if:

1. SUPERUSER_GROUP and/or STAFF_GROUP is not set.
2. "groups" is not in claims.
3. MANAGE_GROUPS is False.

Any of these solutions would work fine from my perspective but the current behavior is broken.