Adds Auth0 template

[fdidron]

Proposal for #108

[kbrandwijk]

You check if the audience matches the Auth0 ClientId. Although this works, it's not the right flow to use. If you follow the standards, the Graphcool back-end would be defined as an API in Auth0. Then, the Implicit Grant flow would be used to get an access_token for the API. Then, your code would kick in, with the access_token received for the API, not the access_token received for the client.

I know I commented before about using the id_token directly, and that works, but it's not a 'proper' OIDC flow...

[fdidron]

Do you mean idToken ? I'm not using the accessToken anymore.

EDIt: Nevermind: I'm reading this https://auth0.com/docs/api-auth/tutorials/adoption/api-tokens

[kbrandwijk]

Yes, and this: https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis And this is the Implicit Grant: https://auth0.com/docs/api-auth/grant/implicit

Sorry for the confusion before, I was thinking pre-OIDC, and cutting corners :see_no_evil:

[fdidron]

Thanks for sharing the links, they are very informative (I'm learning a lot with this).

After going through https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis , I understand that the access token won't include any information about the user. It is fine for the scope of this PR, but I think users will wan't the ability to fetch these data in real life scenarii. In order to keep things separate, would it make sense to have another template that grabs the user info onBeforeCreate of the User model ? I can work on this reusing the code I removed with commit 736c2d1 after this PR gets out the door.

[kbrandwijk]

Yeah, I would go back to access_token + userinfo fetch. But I would also go for defining the API in Auth0 and setting the proper audience in the Implicit Grant authorization call.

[fdidron]

Here is a first stab at it: 1d1cf47

[agustif]

I'll be using this, so thanks for the work @fdidron and @kbrandwijk

[kbrandwijk]

@fdidron I'll have more time to look at it this weekend. But initially, this looks good, although maybe the userInfo call should be reintroduced, as most people would want to check for an existing user by email address, not just auth0Id, and that would give them a good basis to start.

[fdidron]

@kbrandwijk Noted, I'm wondering if I shouldn't create a separate template for fetching the profile.

[frankdugan3]

@fdidron I'm attempting to try this out, and I keep getting:

Error: Unable to retrieve key identifier from token

The error logs indicate that the access token is being passed correctly. I'm having a hard time determining why jwt.decode() is failing. Any thoughts?

[fdidron]

@frankdugan3 Can you paste your access token in here https://jwt.io/ and give me the output of the header section on the right ?

[frankdugan3]

@fdidron Well, that tool has revealed it is an unparseable, short access token. I'm not sure what I'm doing wrong.

[kbrandwijk]

@frankdugan3 I suspect your Auth0 configuration is wrong. Did you follow the steps in the Readme, and created both a client and an API with the correct settings?

[frankdugan3]

@kbrandwijk Ahh, that was my problem. I didn't set up the API side correctly. I feel like Auth0 should provide better errors with this case, because there was nothing apparently wrong, no errors, yet it returned an invalid token. Thank you!

[timwis]

I just implemented this and tested it with a JS client-side Auth0 hosted page - it's almost there! createUser fails because email is not provided. Do you know whether there's a way to get the user's email address from the initial auth0 authentication, or do we need to have the server-side function query auth0 to get the user's email? (I saw a todo about that above, wasn't sure if that means this isn't ready to merge yet or not)

[agustif]

I just want to add one comment, facebook and another OAuth available as integrations in Auth0, do not provide email, so it's up to the implementation to ask for email in case it's needed in the cases that don't provide it, like Facebook.

[kbrandwijk]

The social connections available on Auth0 can be configured to ask for email as well. However, this is not enabled by default, so this PR should be able to deal with not getting it.

[fdidron]

@agustif @kbrandwijk @marktani I added fetching the email from Auth0 if the accessToken's scope includes email

[kbrandwijk]

@fdidron Did you test if that actually works? Because if the email is not part of the scope when requesting authorization (from Facebook for example), then probably the call back will not be able to get it either...

[fdidron]

I tested it with email / password, Facebook, Google and LinkedIn. If the email is not part of the scope, the callback is not fired.

[kbrandwijk]

@fdidron Ah, I saw the guard for that in your changes, but the penny didn't drop... Makes perfect sense.

[marktani]

what a great work, thanks everyone involved 🙏

[rcy]

I am getting an unexpected error when running the authenticateUser mutation that is shown in the example app after successfully authenticating with auth0. This is for users that do not already exist in graphcool. For those that do (they were created by the old auth0 integration), the authenticateUser mutation works as expected.

Here is the error:

{
  "data": null,
  "errors": [
    {
      "locations": [
        {
          "line": 2,
          "column": 5
        }
      ],
      "functionError": "An unexpected error occured",
      "path": [
        "authenticateUser"
      ],
      "code": 5001,
      "message": "function execution error: An unexpected error occured",
      "requestId": "us-west-2:simple:cj9qvxmh5pdf501992jmmni53"
    }
  ]
}

Any ideas how to debug this? I cannot find a backtrace or more details in the graphcool function call log.

[fabien0102]

Simple way: Add a console.log on each code branch ;)

BTW if you can try #121 it can be awesome to have real integration tests :wink:

[marktani]

The most common error I've seen so far, is that the User type in your service has some required fields that are not part of the createUser mutation used in the template. You might need to add those fields.

[rcy]

@marktani, that was it. I had email: String! in my User type, I updated my schema and it works as expected. Thanks everyone for their work on this!