How to access case-sensitive username in backend API?

General
#1

My ultimate goal is to access a case-sensitive version of the username in my backend API. From what I’ve read, we should not include/send this with the access token from the client to the backend API, but instead we should call the /userinfo endpoint from the backend API (using the access token). The username is stored in all lowercase, so I read in another thread that we can store the original case sensitive username as part of the user_metadata. I have created the below rule to try to save the original case sensitive username into user_metadata.

function (user, context, callback) {
  user.user_metadata = user.user_metadata || {};
  user.user_metadata.username = user.username;
  context.idToken['https://example.com/username'] = user.user_metadata.username;

  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
    .then(function(){
        callback(null, user, context);
    })
    .catch(function(err){
        callback(err);
    });
}

I have checked the “Requires Username” field in the dashboard so that the username field shows up on the signup screen. When I sign up a new user, and then later call the /userinfo endpoint (from my backend API), I get a property back that looks like this below, but the value is converted to all lowercase.

"https://example:com/username": "helloworld"

Please let me know how I can achieve what I am trying to do.

Thanks!

1 Like
#2

Hi there again @jrp-23,

I checked with our Senior Support engineer on this one and confirmed that when a username is created within an Auth0 database regardless of uppercase or not, it forces it to lowercase.

If you feel this is something that should be altered or have a use case for it, please share with us at Auth0.com/feedback. Each request is viewed by our Product team and has a direct effect on features and enhancements going forward in our product roadmap. Thanks!

#4

Hi @James.Morrison,

I did submit feedback a few days ago, and someone already reached out for more information.

In the meantime I was wondering if there are any workarounds? I had found in another thread that user_metadata could be used to store original user input (including capital letters). I have been unable to get that to work though. Is that something that should work?

Thanks!

#5

Should work :slight_smile: I tested it along with another engineer. Can you share a example user you are testing this on along with the tenant in a DM? Thanks in advance!

#6

I understand that ID tokens are not meant for authentication/authorization of an API. But is it ok to send an ID token along with the access token to an API? If we use the access token for authentication/authorization, is it ok to use the ID token to store some of the user properties in a database for example? This would avoid having to make a separate call to /userinfo in the backend API.

#7

Are you using a custom database? What about leveraging a call to pull the details from the ID token instead of saving the entire token in a custom database?

#8

I am using an Auth0 Custom Database, vs. using social providers (is that what you were asking?), but my question is in regards to storing certain user properties (e.g. email or username) in my own database (in addition to what gets stored in the Auth0 DB). I’m not trying to save the entire token, I’m just trying to figure out the best way to get certain properties from the ID token into my database.

#9

Hi, I just wanted to follow up with this. I still have not been able to get this to work. Please let me know what I am doing wrong - e.g. is my rule not setup correctly? I can provide additional info if necessary - thanks!

#10

I apologize for the delay @jrp-23, I will dive into this today with another engineer to see if we can make traction on this front. I will be sure to share what we find regardless!

#12

After talking with another engineer I was able to confirm that you would need to write something within your application to decode the token when it gets passed back to your app. It’s in standard JWT format when returned.

#13

Thanks for the info. What is the recommended way to pass an ID token from a client mobile app to an API? I know for an access token we should pass it via the Authorization header, but where do we include the ID token in a request to an API?

#14

@jrp-23 when it comes to working with native apps, we always recommend the Authorization Code grant with PKCE.

You are just trying to pass the data you extracted from the ID token to the request to the API correct? Not the full ID token?

#15

Hi @James.Morrison - yep I am using that flow. So you are suggesting option 1 below? Or could either approach be used? It doesn’t matter to me which I go with, I’m just trying to understand if there are any concerns with either of the approaches and/or if any should be avoided.

  1. validate & extract ID token in client mobile app - then send just the specific fields (username, email) to my API via an http request (pass those fields as query string parameters, or in the request body, etc…)

vs…

  1. pass entire ID token to my API (in the request body?), then validate & extract within the API logic.
#16

Hi @James.Morrison just wanted to follow up again on this to see if you were able to find anything?

#17

Hi @James.Morrison just following up again on my latest question above (with options 1 vs. 2). Let me know if you need any more info. Thanks.

#18

Thank you for following up on this @jrp-23, I’ll make this a priority and see what I can find. Thanks!

#19

After confirming with a senior engineer, this is the best course for you. As if you passed the entire token and it’s mishandled, it could easily end up being a security risk. Thank you for your patience while confirming this.

#20

Great, thank you for confirming.

This thread got split into 2 questions. Do you have any more info regarding my original question/issue related to the case-sensitive username (ultimately achieved via a rule to save original username in user_metadata)? I’m still unable to get that to work.

#21

Hi @James.Morrison - a follow-up question - as soon as I get the id token back from Auth0, i.e. after calling webAuth.authorize(), do I need to validate it right away prior to decoding it? Or can I just decode it without validating it? The reason I ask is because I found jwt-decode which states the below - indicating that validation should take place on the server. Is this the case (or is that more in reference to access tokens rather than ID tokens)? If it is recommended to validate an ID token on the client, do you have any example code of how to do this (in React Native)?

IMPORTANT: This library doesn’t validate the token, any well formed JWT can be decoded. You should validate the token in your server-side logic by using something like express-jwt, koa-jwt, Owin Bearer JWT, etc.

Thanks!

#22

Hi @James.Morrison just wanted to follow up with this thread - have you had a chance to find any more info? Thanks!