OIDC & certwarden:superadmin Scope

jmartindf

Hi,

I've been trying to setup proper SSO with Authentik and OIDC. I've seen the documentation on Idp General Configuration Notes and I've seen the discussion in issue #86 about “OIDC error when using Authentik”.

I’m confused about how this is supposed to work. The documentation implies that the user either does or does not have the scope attached to them. If the user does have the scope, they get access to Cert Warden. If they do not have the scope, access is denied.

But my understanding of OIDC and scopes is that scopes are a way to ask for a piece of information or a set of information. I didn’t think that a scope itself was a yes/no or true/false kind of thing.

If I have a "certwarden:superadmin" scope defined in Authentik, then every user is logged into Cert Warden, regardless of what information I do (or don’t) return as part of that scope. And if I don’t have a "certwarden:superadmin" scope defined in Authentik, then no user can login to Cert Warden.

That feels like a bug to me. Am I misunderstanding how this works?

gregtwallace

I don't use Authentik so I'm not familiar with it beyond the Issue thread you linked to. (The write up in the docs was done by a user, not me.)

I don't think every user should automatically be able to request any scope. For example, Auth0 has a toggle for Enable RBAC to enforce permissions / roles.

What is the alternative suggestion for constraining access?

jmartindf

I think there’s a naming confusion / overlap between OAuth 2.0 and OIDC. In OAuth 2, a “scope” is a specific permission granted to a specific resource. Like “email:read” on the /api/user endpoint.

In OIDC, a “scope” authorizes the application to access certain details about a user, such as name, picture, email, group membership, etc. Each “scope” returns a specific set of user attributes. These user attributes are “claims”.

In the context of OIDC SSO, I would expect a “scope” to result in a specific attribute or set of attributes being returned. In the context of OAuth, I would expect the “scope” to be a specific permission that is granted or denied. And in OIDC + OAuth, I would expect that permission to be returned to the application in a user attribute (“claim”) that’s included in the OIDC ID token.

(auth0 documents these two types of scopes as API Scopes and OpenID Connect Scopes.)

A lot of apps request a “groups” scope that returns an array of enabled groups for the user and then look for a specific group in that array. For instance, here’s a JWT that has a groups attribute (claim) and the “certwarden_superadmin” group is present.

{
     "iss": "https://authentik.domain.tld/application/o/open-id-connect-playground/",
     "sub": "33c23a93d268c2ea088937eb30ab9ad889e9a7dd13419c28e6202a018517b81f",
     "aud": "kbyuFDidLLm280LIwVFiazOqjO3ty8KH",
     "exp": 1751241252,
     "iat": 1751240952,
     "auth_time": 1751231984,
     "acr": "goauthentik.io/providers/oauth2/default",
     "amr": [
      "pwd"
     ],
     "sid": "f582abad5e10b2e908be7c3f4d666ac8cbba457ae229205524fd20c534588526",
     "email": "joe@example.com",
     "email_verified": true,
     "name": "authentik Default Admin",
     "given_name": "authentik Default Admin",
     "preferred_username": "akadmin",
     "nickname": "akadmin",
     "groups": [
      "authentik Admins",
      "certwarden_superadmin"
     ]
    }

But it could easily be a custom claim that simply has an attribute called “certwarden:superadmin” with a true / false value.

{
     "iss": "https://authentik.domain.tld/application/o/open-id-connect-playground/",
     "sub": "33c23a93d268c2ea088937eb30ab9ad889e9a7dd13419c28e6202a018517b81f",
     "certwarden:superadmin": false
    }

That kind of OIDC setup is very easy to do in both Authelia and Authentik. In contrast, trying to manipulate the returned OAuth 2 scopes looks to be entirely undocumented in both apps.