Following the instructions here, I encountered problems when using the suggested URI under the heading Test auth0 login and generate sample JWTs for testing. Two things: first, if you want to use the /login endpoint you have to substitute
response_type=token
with
response_type=token id_token
Second, for the /login endpoint to work, as given in these instructions, you have to disable OIDC Compliance under the Auth0 application you are targeting, found under Applications >
access_denied: Password login via OIDC-conformant clients with externally-hosted login pages is unsupported
I am a beginner at all of this. It may be that these instructions worked before Auth0 disabled "as many legacy features as possible". I quote from auth0 docs. I hope this is useful info.
@fogelfish thank you for reporting this. This is good to know. We will try it out and fix the documentation 馃憤
On a similar note, I've been using the auth0-spa-js sdk recently, and that only returns the auth0 access_token - Not the id_token as the current Hasura guide/tutorial requires.
I found this could be fixed by simply attaching the Hasura namespace claims to context.accessToken rather than context.idToken. Is there any particular reason that the guide currently uses the latter?
Please see https://community.auth0.com/t/how-to-obtain-id-token-with-auth0-spa-js/27574/10 (if it hasn't already been brought to your attention...)
(Happy to submit a docs PR if there is no particular issue with this...)
@thetre97 you're right. The SDK doesn't expose the ID token and they recommend to use access tokens. I'm not sure of the reason(s) though.
Generally speaking, ID tokens are issued to end users, containing user information, and access tokens are meant for applications to access APIs. See [ID token], [Access tokens].
Hasura requires a JWT with the Hasura specific claims, as long as it is there in a JWT it should work.
@thetre97 - Hi, from version 1.2.0 and above, the raw idToken value is available in the getIdTokenClaims method. Here's the reference PR - https://github.com/auth0/auth0-spa-js/pull/175
@praveenweb Great, thanks - will check that out 馃憤
I'm currently evaluating hasura + auth0 flow. One thing I noticed is that auth0 discourages using idToken for API access and instead encourages the use of accessToken. I've also noticed that the ID token can get very large, depending how much user info and metadata is being stuffed into it, so using it for each and every API call as a header does not seem great practice.
Here an extract from docs (https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis#how-not-to-use-tokens)
ID Tokens should not be used to gain access to an API. Each token contains information for the intended audience (which is usually the recipient). Per the OpenID Connect specification, the audience of the ID Token (indicated by the aud claim) must be the client ID of the application making the authentication request. If this is not the case, you should not trust the token. Conversely, an API expects a token with the aud value to equal the API's unique identifier. Therefore, unless you maintain control over both the application and the API, sending an ID Token to an API will generally not work. Since the ID Token is not signed by the API, the API would have no way of knowing if the application had modified the token (e.g., adding more scopes) if it were to accept the ID Token.
You can (and should) use an access token, and it's not too difficult:


const authConfig = {
domain: 'example-hasura-app.auth0.com',
client_id: 'someg0bbledyg00k',
redirect_uri: window.location.origin, // or whatever you're doing for this
scope: 'openid email profile',
audience: 'https://example-hasura-app.herokuapp.com'
}
context.accessToken:function (user, context, callback) {
const namespace = "https://hasura.io/jwt/claims";
context.accessToken[namespace] = {
'x-hasura-default-role': 'user',
'x-hasura-allowed-roles': ['user'],
'x-hasura-user-id': user.user_id
};
callback(null, user, context);
}
Thats some great info @tehpsalmist, thanks a ton for letting me know, it works perfectly, should go directly into official docs!
@tehpsalmist thank you so much for helping out! I make sure this will be added to the docs within the next 2-3 weeks 馃檪
@tehpsalmist I have to echo everyone's appreciation posted the fix. I was banging my head against this for a couple of hours and that change to accessToken fixed my issue!
Hi everyone, @praveenweb and I have tried out the above instructions and we both were not able to get a valid JWT token through the accessToken.
@westhechiang @bkniffler @tehpsalmist @thetre97 We think it might have something to do with Auth0 releasing a new version of their SDK (auth0-spa-js). That SDK didn鈥檛 allow to fetch idToken initially. After a version 1.2.0, they added back a way to fetch the idToken again. Is it possible that you are using a version older than 1.2.0?
@marionschleifer I鈥榤 not using the js library, I鈥榲e implemented everything with calls to auth0 API from electronjs (so nodeJS) and it works pretty great. Thanks for hinting the new SDK though, didn鈥榯 see they have a new one in the works.
Yeah, I'm not sure, but I think I was working on 1.2.3 or something when I submitted my PRs and had lengthy conversations with auth0 about this stuff. I'm spinning up a new app right now, so I'll report back if none of this works.
Upon further reflection, the client-side auth0 library should have no effect on whether the token is JWT or not. The important step is in setting up that API on the auth0 account. Can you post your repro steps?
I'm definitely succeeding again with the above steps, using auth0-spa-js 1.2.4. I had previously been using 1.0.2, so I can now confirm the same steps worked before and after the changes you referenced. Let me know if there's anything I can do to help you troubleshoot your specific difficulties.
@bkniffler @tehpsalmist thank you for your comments and for your help 馃檪
@praveenweb will re-write the guide taking your comments and recent findings into consideration.
@praveenweb also take a look at this: https://discordapp.com/channels/407792526867693568/428469959530643466/630286971700248586 馃檪
Most helpful comment
You can (and should) use an access token, and it's not too difficult:
context.accessToken: