How to require a claim on the access, not id, token

[JessHolle]

It seems that mod_auth_openidc's Require claim authz directive is applied to the id token.

I need to require claim(s) upon the access token (irrespective of which of the supported AuthType's is applied to the given resource).

(Also, I should note that the supported AuthTypes are sorely underdocumented. I'll raise a separate issue on that.)

[JessHolle]

By the way, I say "it seems like" Require claim is applied to the id token in that the documentation is not especially clear in this regard.

Given the various tokens involved, it would be really great to be really clear as to which is being referred to at various points in the documentation.

[JessHolle]

So I have AuthType auth-openidc in my configuration. So does that mean:

1. I should be able to make claims against the access token?
2. I must use this type or oauth20 if I want to do so?

• If so, what if I don't want to allow incoming Bearer tokens for a resource, but still want to require claims on the access token acquired by the auth flow?

[JessHolle]

And if Require claim is supposed to work against access token claims for AuthType auth-openidc, then I must have some other issue.

I've tried to verify a custom claim. auth0 requires that custom claims be namespaced, so I have claim names that are fully qualified URLs (e.g. "https://myco.com/foo/bar"). I've had no luck whatsoever getting this to work. The claim grammar used by this module does not seem to be anticipate claim names containing any "special" characters (e.g. : and .).

I've also tried to verify 1 entry in the space-delimited "scopes" claim. I've had no luck in getting that to work either.

[JessHolle]

Hmm... While using AuthType auth-openidc I just tried to require a very simple exact string claim on the access token with no special characters in the name or value (ala Require claim azp:Xy23fwef or the like -- and double-quoting last arg doesn't help). This failed. So forget the complex name or scopes issues for the moment, clearly the basics aren't working for me here.

[JessHolle]

Ah, but this claim does work when the request comes in a Bearer token.

I don't really need this claim to be enforced when the module just retrieved it from the STS itself. But I do need it enforced when it comes in as a Bearer token. If I have separate URL patterns for OAuth2 vs. OIDC access, then this is clear enough, but how do I achieve that with AuthType auth-openidc?

[JessHolle]

Ah, judicious use of <If "-z req('Authorization')"> seems to suffice, though I'm open to better suggestions.