Closed theonlynexus closed 3 years ago
Hi @theonlynexus, there are many more providers requiring some scope. It might be the openid
one, it might be some other scope, it might be a scope in general, not necessarily the openid
one.
So that falls outside of scope for this module. The user is supposed to configure the provider when initializing Grant.
The oauth.json file contains only the authorization server URLs for the most part because they can be considered defaults.
I'm closing this, let me know if you have any other questions :+1:
The oauth.json file contains only the authorization server URLs for the most part because they can be considered defaults.
Hi, thanks for the reply. My thought was exactly that of defaults: authentication via OAuth, without requesting any other particular permission, is the one default use case that I can think of.
Wouldn't it make sense to provide the appropriate configuration to perform at least that? And I mean for every provider, not just Microsoft.
Having that type of defaults and maintaining them for every single provider will be infeasible in the long run. The OAuth spec is very loose in some areas and it's up to interpretation by the implementators resulting in inconsistencies.
Now I'm seeing your issue in Directus - that platform should expose the configuration options for Grant. Setting up the openid
scope for Microsoft here in Grant does not solve the issue in general. It might solve your particular issue but just that. I'm not fully aware of what Directus offers, but in case they want to support lets say 10 specific providers, they can extend the Grant configuration with the scopes they need by testing each and every provider. In case their goal is to give full flexibility to their users by supporting any provider that Grant offers, then most likely they'll have to expose some or all of the Grant configuration.
Without the minimally required
openid
scope there will always be an error.