Auth0 Home Blog Docs

Different behaviour on second login

second-login-jwt-as-
first-login-jwt-as-i

#1

Hello, I have this issue and I’m not sure whether it is a “bug” or my fault somewhere. Will be really glad if you can help me clarify and may be suggest some reading.
I have updated my hosted page Auth0lock object to inculde a params object with a specified audience
params: {
“audience”: “https://api.webatom.com
}
During the first login I get the usual auth result where I receive the JWT as the id_token and a short string for the access token and I don’t get a message in auth0 about account access request.
During the second and other logins I get what I want. I get the message and I get the JWT as access token and id_token as null.
How do I get that second result from the start, right from the first login? Is that a bug or am I doing something wrong?
Thank you.
PS: I don’t have any rules or hooks implemented at that moment.


#2

There are a few things worth noting here. Technically, at this time, Lock does not formally support an audience parameter. There is indeed some support at the library level, but this is not yet documented and it’s not a final version so you should not be using it.

In addition, the future support for audience in the Lock library is meant for the use cases where you’re using it within your own client application. If your usage of Lock is within the hosted login page then you should not have to configure this parameter. If your intentions are to always use a given audience without having to specify it in each request then you should use the Default Audience settings available in your account General settings. Have in mind that setting this option is a global change so it may impose breaking changes on some client application; if you’re just starting your implementation then setting this should be fine.

In conclusion, what you’re doing is not supported; you should be providing the audience when you redirect to the hosted login page and not within the page itself. If you have a SPA application this would generally be done by proper configuration of Auth0.js which is likely the library you use to redirect to the hosted page.


#3

Setting the global audience didn’t help, still get an opaque access token on the first login and a proper jwt one only on the second and onwards

I guess I could live without the audience but I’m using the angular2-jwt library which attaches the authentication header into the requests. The header is then decoded in my ASP.NET Core part and I can successfully use the [Authirize] annotation to block my api’s from direct access. If I stick an opaque_token in the header (withput the audience) the ASP.NET Core part fails when reading the header and says that audience don’t match which is true.


#4

To be more precise that is what I get if I try the opaque mode and have the [Authorize] annotation set on my API
WWW-Authenticate:Bearer error=“invalid_token”, error_description=“The audience is invalid”, however now I realize that there is the aud: parameter inside the payload and I don’t understand why can’t ASP decode it…


#5

So far I have found an interesting work around…
When an opaque token is returned, you can simply copy its aud hash and paste it into the Audience paramenter when creating the JwtBearerOptions object int the startup class. That fixes the error with the invalid audience when using the [Authorize] annotation in the controller api.


#6

Setting the global audience didn’t help, still get an opaque access token on the first login and a proper jwt one only on the second and onwards

I guess I could live without the audience but I’m using the angular2-jwt library which attaches the authentication header into the requests. The header is then decoded in my ASP.NET Core part and I can successfully use the [Authirize] annotation to block my api’s from direct access. If I stick an opaque_token in the header (withput the audience) the ASP.NET Core part fails when reading the header and says that audience don’t match which is true.


#7

To be more precise that is what I get if I try the opaque mode and have the [Authorize] annotation set on my API
WWW-Authenticate:Bearer error=“invalid_token”, error_description=“The audience is invalid”, however now I realize that there is the aud: parameter inside the payload and I don’t understand why can’t ASP decode it…


#8