Support arrays and non-arrays at the same time as provided role?

[yobottehg]

From the clients IDP we either get "role1" as string if the user has one role or ["role1", "role2"] as array if the user has multiple roles.

Supporting both formats at the same time is currently not possible if i see that correctly (even with #3813) ?

[taimoorzaeem]

Supporting both formats at the same time is currently not possible if i see that correctly (even with #3813) ?

Yes. If you plan to use multiple roles with #3813 then I think you should always get your roles from client in an array.

[steve-chavez]

Yes, the full JSONPath as described by RFC 9535 supports boolean logic. I have written the fully compliant library aeson-jsonpath for this.

Cool! I'd agree to integrate the library if it is backwards compatible and if we can ensure no perf is lost (IIRC Aeson always had perf issues). For the latter, maybe we could add a loadtest with a complex jwt-role-claim-key expression.

But, our string comparison feature is a custom feature which is not supported in the RFC. 🤔

@taimoorzaeem Wait, I'm lost. I always thought we were following the RFC, I see nothing on https://docs.postgrest.org/en/v13/references/auth.html#jwt-role-extract that says we're not. Perhaps you can edit the docs to clarify that?

The JSONPath at the very least expects the input to be JSON so I simple string by any identity provider wouldn't cut it.

I was assuming here that the role is still a JSON string? I don't think this request would make sense otherwise. @yobottehg Can you provide sample JWTs (with mangled data to be safe) to confirm?

[wolfgangwalther]

Yes, the full JSONPath as described by RFC 9535 supports boolean logic. I have written the fully compliant library aeson-jsonpath for this.

Cool! I'd agree to integrate the library

Subject to whether it builds for static and cross, i.e. can be built and used without template-haskell. I tried, and it seems that's the case, as long as we're not using any of the quasi quoters in the library.

[taimoorzaeem]

Perhaps you can edit the docs to clarify that?

Although the RFC is still a "proposed" standard, yes I think we should clarify that.

I was assuming here that the role is still a JSON string? I don't think this request would make sense otherwise.

Sorry, my bad. A regular string would be valid JSON string, and the aeson-jsonpath library should work with that.

[taimoorzaeem]

BTW, the original issue still holds and the integration with library wouldn't help for cases with inconsistent JSONs. For example, jwt-role-claim-key = '.roles[0]' would be only be valid for that consistent JSON structure. When string changes to array we would also have to change the jwt-role-claim-key. AFAICT, there is no way to support different JSON structures without also changing the role claim key.

[steve-chavez]

AFAICT, there is no way to support different JSON structures without also changing the role claim key.

True, now I got it. As you mentioned before, the only solution here is for the JWT producer to always send a role array, even if there's only one element. Otherwise I'd argue the producer would be faulty, likely could cause trouble in other JWT consumers too.