Authorization Schema Directives with OpenID Connect (oidc)

[styk-tv]

@johnymontana Will,

You mentioned in your legendary article here that you guys are working on Authorization Schema Directives so context of JWT token details can be used for 1) role-based-access-control and 2) as part of query for current-user data.

Is there any progress on that? I couldn't find any mentions in the new docs. How far down in priorities is the implementation of those features? Would be great to do this on schema definition level. (what group listed in token could run a particular query)

Please consider below example of Kubernetes oidc settings

spec:
  kubeAPIServer:
    oidcIssuerURL: https://your-oidc-provider.svc.cluster.local
    oidcClientID: kubernetes
    oidcUsernameClaim: email
    oidcGroupsClaim: groups  

Then in our JWT token:

Reason I'm listing this is I believe it is important to observe implementation that cares where the GroupClaims are coming from. As you are crafting the token, groups can be placed in different locations. I use groups, but as you are defining a mapping it could be any name. I have not seen such placeholder in the neo4j-graphql-js Discovery specification. I would kindly ask you consider this during implementation.

1. oidcIssuerURL: (server + realm) from which the .well-known endpoints can be derived (usually by affixing .well-known/openid-configuration)
2. oidcClientID: there might be one but as much as hundreds of clients (consumers) of the oidc details in a single realm. Each could have different flows of authorization or mappings (what data is in the token)
3. oidcUsernameClaim: what field is defines the unique user identifier
4. oidcGroupsClaim: what field holds the list of groups that user belongs to (based on this we can grant permissions to different api endpoints) could be as easy as pets_read, pets_write, admin or as complex as required to handle enterprise-level ldap-provided group membership mappings that span across hundreds of endpoints.

Personally I have both beautiful dreams and nightmares about this section for a long time. I think for all of us, getting to a point where you can use abstracted system like Keycloak, Auth0, Google, Cognito ... with or without federated LDAP that admit control to selected endpoints based on token's self-contained details is very long awaited.

[michaeldgraham]

https://github.com/neo4j-graphql/neo4j-graphql-js/issues/608