[BUG][DOCS] Integrate Auth0 as an Authentication Provider

[gander]

Description

It concerns article "Integrate Auth0 as an Authentication Provider", from which I also used example "SurrealDB Auth0 Authentication Example" to make sure I did the entire process correctly.

The article provides an example of the Auth0 action code to implement: "Creating a custom Auth0 action to add claims for SurrealDB"

The problem is that the private custom claims are not added to the payload (Migrate Custom Claims: Restricted claims), so they are not delivered to SurrealDB, and there is still an authorization problem.

After a few days of experimenting, I found in the "Using Tokens" documentation that I could add the https://surrealdb.com/ namespace.

This now works properly.

Fixed action code:

exports.onExecutePostLogin = async (event, api) => {
  if (event.authorization) {
    // The claims in this block are expected by SurrealDB.
    // These values should match your SurrealDB installation.
    api.accessToken.setCustomClaim(`https://surrealdb.com/ns`, "test");
    api.accessToken.setCustomClaim(`https://surrealdb.com/db`, "test");
    // These values correspond to the names of the SCOPE and TOKEN resources 
    // which will be created in SurrealDB during the next section.
    api.accessToken.setCustomClaim(`https://surrealdb.com/sc`, "user");
    api.accessToken.setCustomClaim(`https://surrealdb.com/tk`, "auth0");

    // In this block, we will add additional claims which are not required by SurrealDB.
    // These claims can be used from SurrealQL to implement application logic.
    // In this example, we will add the data that we will store for each user.
    // We will also use some of this data to perform authorization.
    api.accessToken.setCustomClaim(`https://surrealdb.com/email`, event.user.email);
    api.accessToken.setCustomClaim(`https://surrealdb.com/email_verified`, event.user.email_verified);
    api.accessToken.setCustomClaim(`https://surrealdb.com/name`, event.user.name);
    api.accessToken.setCustomClaim(`https://surrealdb.com/nickname`, event.user.nickname);
    // removed due "Uncaught (in promise) DOMException: String contains an invalid character" error
    // api.accessToken.setCustomClaim(`https://surrealdb.com/picture`, event.user.picture);
  }
};

---

I think a note like this would be useful:

If your SurrealDB instance is behind some proxy, e.g. Cloudflare, and you are getting CORS errors, you need to set the Access-Control-Allow-Origin header.

Is there an existing issue for this?

• [X] I have searched the existing issues

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[gguillemas]

Thank you @gander for reporting this issue! Looking at the documentation that you linked, it seems that none of the claims that are mentioned in the tutorial are listed as restricted claims, but I see that there is a restricted token audience section that mentions that non-namespaced claims are removed when the target is an Auth0 API, which is the case when following the tutorial. I don't believe that was the case previously, so I will review this and update the documentation :+1:

[gander]

This PR https://github.com/surrealdb/surrealdb/pull/4061 will solve the requirement to set a full namespace for custom claims., e.g. $token['https://surrealdb.com/email'].

Full working example: https://github.com/surrealdb/surrealdb/issues/4058#issuecomment-2118458590

[gguillemas]

For now we have decided to update the documentation to accurately reflect the current behavior. We have also updated the Auth0 tutorial to reference the restricted claims and the requirement to use a namespace prefix.

Thank you for the report!

[gander]

When I used this example, Auth0 required me to communicate https even for testing. I don't know if it's just me, but that's the only reason I sent it to Cloudflare Pages, unknowingly adding to CORS configuration issues. Give it to someone to test, preferably with different environments (win, lin, mac) so that it is always true.

[gander]

By the way, you can explain that SurrealDB CREATE is protected against cheating, i.e. I authorize myself with a token but I try to create another account, it won't work because email = $token['https://surrealdb.com/email']. It's not always obvious, and I was a little worried about it until I tried it for myself