Currently, Scaphold only accepts loginWithAuth0Input if the idToken using HS256. This means that we can't easily extract data from the social provider during authorization, which means lots of extra steps to get the same data that is already provided via the parseHash method in auth0-js.
Doing so would enable hopeful users like myself to properly initialize new accounts with minimal extra steps....
Here is the workflow that could be achieved without doing a bunch of changes to the default queries:
const Component = (WrappedComponent) => {
const WithAuth = ({ history, location, loginWithAuth0, updateUser, session }) => {
const webAuth = new Auth0JS.WebAuth({ ...init })
const authorize = webAuth.authorize( ...connection )
const processAuth = () => {
webAuth.parseHash(...result => webAuth.client.userInfo(result.idToken, (...user) => {
loginWithAuth0(result.idToken)
.then(res => {
// Sets the token in the location state so the Apollo client can pick it up for the next request
history.replace({
...history.pathname,
location: {
state: { idToken: res.idToken }
}
})
return res.data.logUserWithAuth0.user.id
})
.then(id => updateUser({ id, ...user }))
.then(() => history.replace({ pathname: redirectOnSuccess, location: { state: { success: true } }}))
.catch(err => log(err) && history.replace(...redirect and set error on location state))
}))
}
// This goes on your dedicated callback route
const authenticate = () => {
const matchingHash = /access_token|id_token|error/.test(location.hash)
if (!session && matchingHash) {
processAuth()
}
}
return <WrappedComponent authorize={authorize} authenticate={authenticate} />
}
return WithAuth
}
So this workflow works great sans not being able to use parseHash to get the data inline during the auth flow. I tested it out by adding the fields I wanted to save on the User model, the manually specifying the user info i wanted to add during the first update.
I also played around with code signing at https://jwt.io/ - and using the certificate provided by Auth0 to sign the hash generated by Auth0 when in RS256 mode.
I'll be the first to admit that I'm no expert on JWT and security, but wouldn't a viable path forward be to replace signing the JWT token with the private key, and instead allow us to copy/upload the signing certificate from Auth0 for use within the Scaphold Auth0 Integration Config.
...it sure would be nice, but as of right now, attempting to make an update request with a RS256 JWT token always results in a 401 being returned from Scaphold...making auth0-js pretty much worthless...
Why
loginWithAuth0Input
if theidToken
using HS256. This means that we can't easily extract data from the social provider during authorization, which means lots of extra steps to get the same data that is already provided via the parseHash method in auth0-js.Here is the workflow that could be achieved without doing a bunch of changes to the default queries:
So this workflow works great sans not being able to use
parseHash
to get the data inline during the auth flow. I tested it out by adding the fields I wanted to save on theUser
model, the manually specifying the user info i wanted to add during the first update.I also played around with code signing at https://jwt.io/ - and using the certificate provided by Auth0 to sign the hash generated by Auth0 when in RS256 mode.
I'll be the first to admit that I'm no expert on JWT and security, but wouldn't a viable path forward be to replace signing the JWT token with the private key, and instead allow us to copy/upload the signing certificate from Auth0 for use within the Scaphold Auth0 Integration Config.
...it sure would be nice, but as of right now, attempting to make an update request with a RS256 JWT token always results in a 401 being returned from Scaphold...making auth0-js pretty much worthless...