https://www.prisma.io/ logo
Join Slack
Powered by
the auth0 authentication piece is working just fin...
# prisma-whats-new
d
the auth0 authentication piece is working just fine it seems
w
@dkh what does your createUser mutation look like?
d
Copy code
export default gql`
   mutation ($idToken: String!, $name: String!, $username: String!, $email: String!, $avatar: String!){
    createUser(
      authProvider: {auth0: {idToken: $idToken}}, 
      name: $name, 
      username: $username,
      email: $email, 
      avatar: $avatar
    ) {
        id
      }
  }
`
w
I do mine slightly differently, but it looks good
Copy code
mutation ($firstName: String!, $lastName: String!, $email: String!, $authProvider: AuthProviderSignupData!){
          createUser(firstName: $firstName, lastName: $lastName, email: $email, authProvider: $authProvider) {
            id,
          }
d
Gotcha, yeah looks like you just have the autProvider piece defined in another variable
w
and you are pulling the idToken out of the data structure similar to this?
Copy code
lock.on('authenticated', (authResult) => {
        const {idToken, accessToken, idTokenPayload: {exp}} = authResult;
d
const idToken = localStorage.getItem('id_token')
w
I mean, when you extract it initially
and save it to the local storage
d
yup,
Copy code
handleAuthentication() {
    this.auth0.parseHash((err, authResult) => {
      if (authResult && authResult.accessToken && authResult.idToken) {
        this.setSession(authResult);
      } else if (err) {
        history.replace('/');
        console.log(err);
      }
    });
  }
Copy code
setSession(authResult) {
    // Set the time that the access token will expire at
    let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
    localStorage.setItem('access_token', authResult.accessToken);
    localStorage.setItem('id_token', authResult.idToken);
    localStorage.setItem('expires_at', expiresAt);
    localStorage.setItem('authResult', authResult)
    // navigate to the home route
    history.replace('/authenticate');
  }
I just followed the auth0 React quick start example and tweaked it a bit
w
is it possible that when you create your 
new Auth0Lock(CLIENT_ID, AUTH0_DOMAIN, {});
that the clientId and domain don't match up with the secret that you set in the graphcool dashboard?
remember that if you change an environmental variable, you will likely have to stop/start the dev process/server to get those changes to take effect
d
I'm actually using auth0.WebAuth
and for now, I'm not using env vars, just hard coded the domain and clientid
w
ok, but they look correct?
d
yup, doesn't hurt to replace them though and try again
yeah, still seeing the same error. Bizarre that the id_token is in local storage but the mutation doesn't like it
w
I guess the next thing is to check in your browser's dev tools, in the network requests to be sure that the token is actually being sent. And you can try manually running the query in the graphcool dashboard's playground to narrow down the problem as well
d
👍 will do, thanks a lot for your help!
w
good luck!
you can also test tokens here to see if the token and the secret match up
n
@dkh we currently only support H256 tokens
is auth0.WebAuth 
auth0-js
?
d
yup
n
that uses R256 tokens in version 8. You can use version 7 instead
d
ahh, gotcha. I can just use auth-lock
n
make sure to use H256 as encoding method in the Auth0 settings though
d
ok cool, will do!
p
@dkh I'm using 
auth0-js@8.8.0
to implement custom login/signup and I've managed to succesfully implement it with manually parsing 
id_token
information from URL hash (as 
parseHash
in v8 cannot parse HS256 tokens yet, as mentioned in https://github.com/auth0/auth0.js/issues/303#issuecomment-273851977)
I'm using 
qs
lib for parsing and something like this:
Copy code
import qs from 'qs'

let hash = window.location.hash;
hash = hash.replace(/^#?\/?/, '')
const authResult = qs.parse(hash)

if (authResult.error) {
  dispatch(signupFailed(authResult))
} else {
  dispatch(signupSuccessful(authResult))
}
d
Ahhhh, very nice @petr.vlcek. Thanks for the tip!
salute 1
p
it's also worth noting that when you use 
audience
option for new instance of 
auth0.WebAuth
or when you turn on OIDC on your Auth0 client (in advanced settings), Auth0 automatically starts sending you RS256 idToken instead of HS256 token regardless of your client JWT signature algorighm settings
d
@petr.vlcek interesting, so I should remove the audience setting as well?
p
yes, after removing it, you start receiving idToken in HS256 format
I've just tested it
d
crazy, ok gotcha
p
it's maybe because of compliance with some standards (which I don't understand deeply :))
d
hahaha yeah, I’m right there with you man
Open in Slack
PreviousNext
Powered by