Closed kbrandwijk closed 6 years ago
Can you elaborate on the use cases this would enable?
@sorenbs This is part of a bigger proposal I made here: https://github.com/graphcool/feature-requests/issues/137#issuecomment-321384222. Using a standard token structure helps when the token is not used as an opaque token, but the claims are actually used in the client. Many large systems use the same standard (like Microsoft, Auth0 and many others), so knowing what to expect helps when using certain client libraries. It also helps in RP/SSS/SE, depending on the use case.
@sorenbs I came across a resource that clearly describes the authentication flow, that is OIDC compliant, that one could implement when Graphcool uses OIDC compliant tokens. It's the 'implicit grant' model, that allows you to define Graphcool as an API in Auth0, and use the token mechanism described on this page: https://auth0.com/docs/api-auth/grant/implicit. Any other Auth0 integration is not compliant and will definitely fail any pentest. I strongly urge you, as I have done in other FR's, to rethink your strategy for implementing a OAuth2 flow. This includes providing an oauth authentication endpoint directly from Graphcool, and other necessary elements.
I believe your proposal can be rephrased as "Allow accepting OIDC tokens". Out of the box it will allow all Identity providers that support openidconnect to issue tokens that Graphcool can then use, so the integration part would simply be adding the url of the authorization server as everything else could be automated using discovery!
This issue has been moved to graphcool/graphcool-framework.
In order to increase compatibility between systems, please consider adopting the OIDC specification for token formats. https://openid.net/specs/openid-connect-core-1_0.html, for example, instead of specifying
userId
andmodelName
in the token, you could specifysub: 'User|c3.....'
andtid
instead ofprojectId
in the token.