Custom Claims not being added for expo requests

Hi,

Not sure if this is the correct category and I have been looking through multiple threads and having issues finding any answers. I have created an expo app and utilised the auth0 example from the following link:

Having configured the app using this mechanism I have been able to retrieve a JWT however the JWT does not have any of the custom fields attached which should be being attached by rules on the auth0 side. I have tried this with other flows and the JWTs do contain the extra information I expect. I assume I am being stupid here and don’t fully understand the underlying mechanism that is making the call to auth0 which for some reason returns a JWT without running the rule and adding the extra information.

Does anyone happen to have experience with this form of authentication and can point me in the right direction? The API documentation on expo side seems to be rather confusing so I am not sure if I need to have a different request type? or is the /autorization the correct endpoint vs something like /oauth/token?

Any advice would be greatly appreciated this one is a blocker for me and is a real butting my head against the wall! Thanks in advance!

1 Like

Hi @clee,

Can you share the rule you are using to set the claims?

Hi,

I run the following rule function:

function (user, context, callback) {
  const namespace = "https://example.com/jwt/claims";
  context.accessToken[namespace] =
    {
      'some-key': 'user.value_i_want',
    };
  callback(null, user, context);
}

This runs perfectly fine for any time I call this mechanism through a react native app but doesn’t support expo. So I am confident that this issue is not with the rule but rather in how the endpoint is being called? For some reason the expo-auth-session library’s request does not trigger a fully formed token to be returned. Is there additional scopes that are required? I had tried adding offline but is there more to be added?

As expo is an extremely common framework is there a clear step by step example of how to use auth0 with the expo’s auth-session implementation? Other products such as okta have clear step by step guides available and there seem to be a ton of requests on the forms about this sort of issue.

Please find the following link which contains many guides for various auth providers but does not seem to contain auth0: Authentication - Expo Documentation

Hi @clee,

Is your token not a jwt? You may be missing an audience param with the initial request.

Hi Dan,

Yeah my token is a jwt. I tried adding audience to the extra params of the expo-auth-session but still seems to return a jwt that doesn’t include the added information added by the rule. It seems that using expo with auth0 should be a relatively common situation is there a reason why there is no documentation or working example for expo? Can this be requested? I have seen quite a few requests for one and there is a lot of discussion in expo trying to understand why the interaction is different on auth0 from other providers which do seem to accept the session.

This experience is INCREDIBLY frustrating and causes huge delays going through entire frameworks in depth undermining the entire point of using an auth provider which is to simplify the process.

Also to add to the above I have looked through multiple potential implementations. I am unsure whether my request using extra parameters makes it to the auth0 request? Maybe it doesn’t, however I am unable to find anything in the logs to provide me with any insight into how it is communicating with auth0.

Looking at the implementation I first mentioned you would think that the following request should provide the correct token with the values I expect:

const [request, result, promptAsync] = AuthSession.useAuthRequest(
    {
      redirectUri,
      clientId: auth0ClientId,
      // id_token will return a JWT token
      responseType: 'id_token',
      // retrieve the user's profile
      scopes: ['offline_access', 'openid', 'profile', 'email'],
      extraParams: {
        audience: auth0Audience,
        // ideally, this will be a random value
        nonce: 'nonce',
      },
    },
    { authorizationEndpoint }
  );

However I am not sure that the extraParams with the audience even get populated across or how they are formed. At this point I am unsure whether I spend hours down the rabbit hole looking into how this library implements this call and handles extra parameters and if those extra parameters will be ingested by auth0…

Information on the Request can be found at this link: AuthSession - Expo Documentation
Information on the Request configuration can be found at this link: AuthSession - Expo Documentation

Or should I not be trying to do this as a cohesive best practise style steps? Will I have to manually attempt to handle the individual calls of the pkce flow myself something such as the following link: Auth0 Authorization Code Flow with PKCE using Expo AuthSession — JAMES IRISH

Either way this is a real disappointment for the developer experience especially given there are multiple auth0 repos of “examples” which seem to be abandoned or deprecated with no reasoning. Am I the only person using auth0 with expo that needs to have a rule add a value to a token? Surely not? At this point an answer of “we haven’t even bothered with doing anything with expo and don’t know if it would even work” is at least a solid answer that allows me to know that this isn’t a tested situation that is expected to work

1 Like

Let’s start with one thing at a time.

I suspect that you are requesting an id token (look at the responseType in your useAuthRequest() method) but you are adding the claims to your access tokens (look at your rule). This would explain why you aren’t seeing the claims returned in the token.

You can create a request here. This will help us track interest. I can’t speak to why there isn’t an existing example outside of the one hosted in the expo repo.

I apologize for your frustration. We obviously want to provide a smooth experience, but it happens that not every framework and use case is covered. Expo happens to be one of the frameworks that don’t have a comprehensive example, and I am doing my best to support you through it. I ask that you keep things civil and respectful through the process.

Hi Dan,

Firstly and most importantly let me extend my sincerest apologies if I have offended you in any way that was certainly not my intention, but my intention was rather to be open and “call a spade a spade” style triaging and I completely agree that any issue should be handled in a civil and respectful manner. In text tone and intention can often come across differently than the desired way they are meant and some of my comments can definitely be read with a different meaning without the correct tone. Going forward I will ensure I am more clear around my wording choice. Thank you for calling this out and I apologise that I did not pick up on this sooner, please chalk it up to too many hours starring at a screen and careless typing rather than an intention to be uncivil or disrespectful.

With that said, the key issue I am having is in achieving an outcome rather than a solution. Starting with a solution in mind often can lead you astray of getting the exact answer, sometimes even a negative answer. But an outcome can be negative such as “unsupported” or something to that effect.

To restart and provide clarity as to the issue being discussed I’ll try to summarise and provide a list of open questions to help get us moving constructively.

The perceived issue I have is in trying to accomplish an integration between expo and auth0 I have came across a situation where the standard request does not respond with the token I expect. I say perceived specifically as this may or may not be an issue. This may very well be intended functionality.

During trying to resolve this issue I have noticed numerous threads and posts regarding the issue on both expo and auth0 forms and github repos. However I want to ensure I go by the best practices of my secure auth provider rather than an expo implementation which may overlook an important security requirement as some of them do.

Having seen a number of these threads without a full clear consistent resolution (such as a blog post etc) with the auth session library expo uses leads me to question my assumption of if this is the correct way to be solving this problem. Perhaps there is an alternative method I am not considering such as a one-time-password process or something that might achieve the same thing but a different implementation. I guess it’s just coming down to getting clarity around what is officially supported and tested against vs there being no officially supported implementation, which is completely fine as it comes down to a question of how many users are asking for a specific thing vs the resource you have to commit to various asks etc.

Thank you for your consideration, patience and any guidance you have to offer on this matter.

1 Like

Added request for new tutorial, anyone viewing this thread that finds themselves in a similar position please go over and give it a vote! Thanks

1 Like

It’s no problem, I understand that it can be frustrating and I find your feedback to be extremely important. Thanks for creating the feature request, that is the best way to voice your feedback and get input from the community and team.

I think this part of my previous message may help to find a solution for your initial issue. Let me know.

To address some of your other concerns about best practices, officially supported, etc.: unfortunately, there isn’t a full-fledged example for expo from Auth0 at this time, like you have previously mentioned, and it looks like the example from Expo does not have constant support. I can try to help you debug the issues you run into, but can’t provide a full example at this time. Thanks for you patience.

1 Like

Hi @clee, have you been able to get it working? I’m trying for many days now, but no luck.

kind regards

1 Like

Switching the response type from “id_token” to “token” fixed the problem for me.
Thank you for the suggestion!

2 Likes