Auth0: User password /email change

[JakeIwen]

There is an insane amount of documentation regarding setting up management/server/client APIS for auth0.

The BT AuthService is probably the most difficult code for me to follow, but as far as I can tell it doesnt seem to be able to be easily modified to allow for the authorization to change user passwords.

Just wanted to check to make sure you don't know of anything already in place that will help me.

So far i have established the bt-api as a resource server. It seems I am supposed to get temporary client-grants with bt-api using the Bearer token I generated, and provide those grants to the BT App.

Here's a few things I wrote. the first function will actually change passwords, but apparently you are not supposed to do it directly with this method. The second one is what successfully established the API as a resource server, and the third one returns "unauthorized" when I try to get a client grant.

Any advice in general for approaching this problem?

const {auth0API, auth0Secret} = process.env

export const setPass = (newPass, auth0Id) => {
  let url = "https://bouncetribe.auth0.com/api/v2/users/" + auth0Id

  let options = {
    method: "PATCH",
    body: JSON.stringify({ 'password': newPass }),
    headers: {
      Authorization: "Bearer " + auth0API,
      "Content-Type": "application/json"
    }
  }
  return new Promise( (resolve, reject) => {
    fetch(url, options)
    .then(result => result.json())
    .then(response => console.log('response', response))
  } )
}

export const makeResourceServer = () => {
  let url = 'https://bouncetribe.auth0.com/api/v2/resource-servers'

  let options = {
    method: "POST",
    body: JSON.stringify({
      name: 'Bouncetribe API',
      identifier: 'https://bt-carl-api.herokuapp.com/',
      signing_alg: 'RS256',
      scopes:  [{value: 'resource_server'}]
    }),
    headers: {
      Authorization: "Bearer " + auth0API,
      "Content-Type": "application/json"
    },
    json: true
  }
  return new Promise( (resolve, reject) => {
    fetch(url, options)
    .then(result => result.json())
    .then(response => console.log('response', response))
  } )
}

export const getClientGrant = () => {
  let url = "https://bouncetribe.auth0.com/oauth/token"

  let options = {
    method: "POST",
    body: JSON.stringify({
      grant_type: 'client_credentials',
      client_id: '22XLjQyIPQV2Y2jQe4c7Qh-WqwUYcwNR',
      client_secret: auth0Secret,
      audience: 'https://bt-carl-api.herokuapp.com/' }), //TODO
    headers: {
      // Authorization: "Bearer " + auth0API,
      "Content-Type": "application/json"
    }
  }
  return new Promise( (resolve, reject) => {
    fetch(url, options)
    .then(result => result.json())
    .then(response => console.log('response', response))
  } )
}

[carlpeaslee]

So I think this is being done in a bad way currently. I believe I currently have a token with a lifetime grant that is being loaded as an environment variable.

Here is a file from a new project that does things better: https://github.com/artsmia/mia-storytelling/blob/master/server/src/auth/management.js.

Basically, you should keep a token with an expiration in memory or in a file (that is .gitignored) and then before each request, check to make sure it isn't expired and then use refresh it if it is.

[carlpeaslee]

(If you want to continue to use the token with the lifetime grant –– bad –– it is in the api's heroku environment variable configuration)

[JakeIwen]

Not sure if we are on the same page here...

It sounds like in your first sentence you are describing what I just implemented and was asking you about... I wrote the above code... The only Auth0 tokens in the heroku config variables are the ones I just added. the only other existing one was for Spotify

Based on auth0 documentation I think it IS okay to have a lifetime 'Management' token stored in .env, but ONLY for our API. This because we need the Management token to procure user-specific client-grant tokens (which are only good for 24hrs). I'm asking for help using the lifetime token to procure the short term client-grant token. Apparently its bad form to use the Management token to directly edit specific user data, hence the client-grant tokens.

Haven't checked out your link yet but - your third sentence sounds a lot like what think you have set up on BT now... Get the user token back from the auth0 lock (so no Management token is needed) and store it in localStorage. Those DO expire.. those tokens are not client-grants, and do not allow changing of passwords etc.

Will check out your link tomorrow thanks

[carlpeaslee]

Oh, ok. I guess I didn't exactly understand.

Yeah we can talk about this today.

[carlpeaslee]

{ "grant_type": "client_credentials", "client_id": "GBT5jgH1ZwzyxjNg0wZprruli7XAe96r", "client_secret": secret, "audience": "https://bt-carl-api.herokuapp.com/" }