SpringBoot OAuth cannot handle access token

[anschm]

After migrating auth0-angular from version 1.11.0 to 2.0.1 our backend cannot handle the access token. The server response with 401. In addition we are extracting the pernissions from the access token within the frontend by decoding the access token with jwt_decode. With version 2.0.1 the access token cannot decoded with jwt_decode.

[frederikprijck]

Thanks for reaching out, are u using an audience and setting it inside authorizationParams ? If not, it's not a JWT and can't be decoded as such.

See the migration guide.

If that doesn't help, please share the code you had for v1, and the code you have for v2 that's causing the above behavior so we can help solving it.

[anschm]

Yes, thats what I did. I followed the migration guide and set the audience inside authorizationParams.

[frederikprijck]

Thanks, can you please share something for us to look into? As I can not reproduce this (I am getting a valid JWT), It's impossible for us to understand what could be causing this without seeing any code, or reproduction.

Also important to note is that our SDK doesnt generate any tokens, all you need for a valid JWT is to pass the audience correctly. So if you are getting an access token that can not be parsed as a JWT (you can verify on jwt.io), there is something wrong with sending the audience to auth0.

If you can parse it with jwt.io, but not with your SpringBoot backend, there might be a different issue.

[anschm]

Thank you for your answer. Now it works. I set the wrong audience. It's my failure ... sorry for that.

But I have another curious behaviour. In the previous version (1.11.0) authService.isAuthenticated$ method returns true after refreshing the browser for an logined user. Now it returns false and after calling loginWithRedirect authService.isAuthenticated$ returns true immediatly without showing the login screen.

[frederikprijck]

I assume you are using refresh tokens without local storage. If u are, that is because, as mentioned in the migration guide, we no longer us the default iframe fallback.

If u want to restore that behavior, set useRefreshTokensFallback to true.

[anschm]

Oh okay, is it recommended to use the localStorage as cache location?

[frederikprijck]

No, that's not what I am saying. It's perfectly fine to set useRefreshTokensFallback to true if u want that. It's disabled by default because some browsers block it, and more will block it in the future.

[anschm]

Yes I understand your point, but what I am missing is an alternative solution for my described behaviour which is recommended to use. So if more and more browser will block the iframe solution which I can understand why, we need another solution which is recommended and save to use. That is for what I am asking for. For now I can set useRefreshTokensFallback to true. It works for now, but not in the future.

[frederikprijck]

Ah sorry for misunderstanding.

I want to clarify that more and more browsers will block third party cookies. What the ideal solution for this is, is using custom domains. When you ensure your application runs on the same domain as your Auth0 tenant, you avoid using third party cookies and you can again use iframes.

If custom domains is not an option, you can:

• call loginWithRedirect on page load when getTokenSilently fails; as you noticed it doesn't ask for credentials when not needed so users might not even notice it.
• Use local storage; However, this has security implications.

Local storage should be your last resort, and you should understand the implications and also be sure you do need it.

E.g. if you can use custom domains on production, but not on dev/test/qa environments, you might be fine to use loginWithRedirect on those environments, and rely on iframes on production. That way you can avoid local storage.

That said, we have local storage, so you can use it. Just be mindfull about it.

[anschm]

Okay, thanks. Now I understand. We use custom domains on production. So we set useRefreshTokensFallback: true. Thanks for your help.