Can't get around Intelligent Tracking Prevention with Refresh Tokens

Help
, ,
1

Please include the following information in your post:

  • Which SDK this is regarding: e.g. auth0-node

auth0-angular

  • SDK Version: e.g. 2.29.0

1.3.2

  • Platform Version: e.g. Node 12.19.0

Node 14.15.0

  • Code Snippets/Error Messages/Supporting Details/Screenshots:

I am trying to get auth0-angular working for browsers with Intelligent Tracking Prevention, in particular Firefox, Chrome or Safari on iOS. I mentioned the issue on the GitHub project, and was referred to the FAQ, saying that I could work around the login issue by implementing Rotating Refresh Tokens:

There was no guide I could find on how to implement this in auth0-angular, but I did find this community post that was helpful:

In short, I:

  • Added useRefreshTokens: true to my AuthModule.forRoot() config.
  • Enabled the Rotation switch on my Application’s page, and set Reuse Interval to 30.
  • Enabled Allow Offline Access on my API.

But still, after that, refreshing the page logs me out in all my iOS browsers, unless I enable cross-site tracking.

Any help would be appreciated.

Is this a feature request or bug report? If so, please create an issue directly in the corresponding GitHub repo. The Community SDK category is for general discussion and support.

2

Hi @mayhew3,

This can sometimes happen if the audience and/or scope is not included in the AuthModule.forRoot() or if you are requesting an access token for a different audience at a later point. Could this be the case for your app?

Also, are you using cacheLocation: "localstorage"?

4

I wasn’t using localstorage before, but I am now, and am still having no luck. I wasn’t including any additional scope. Do I need to? I see offline_access is required, but I thought I’d read enabling ‘useRefreshTokens’ did that under the covers. However, I tried with and without including that as well.

Here is my code:

AuthModule.forRoot({
domain: environment.domain,
clientId: environment.clientID,
redirectUri: ${window.location.origin},
audience: ‘https://uncharted-insights.herokuapp.com’,
useRefreshTokens: true,
cacheLocation: ‘localstorage’,
scope: ‘offline_access’,

  // Specify configuration for the interceptor
  httpInterceptor: {
    allowedList: [
      {
        uri: '/api/*',
        tokenOptions: {
          audience: 'https://uncharted-insights.herokuapp.com',
        }
      }
    ],
  }
}),
5

Yes, offline_access is required if you’d like to use a Refresh Token. That is okay that you are not including other scopes. The issue I’ve seen in the past is a result of setting scopes/audience in the AuthModule.forRoo and then making another request after authentication takes place with a different audience/scope. It doesn’t sound like that is the issue here.

I’m having trouble recreating this issue in Safari. Could you generate and send a HAR file to help me troubleshoot? Be sure to remove any sensitive data:

Thank you!

6

How can I send it to you? It won’t let me attach it because it’s too big (11 MB). And I can’t attach a .zip file because it says it’s the wrong file type.

8

Hi,
I was able to isolate the issue. It appears that some of my protected APIs were being called upon page load before the auth service was fully authenticated. These APIs didn’t throw an error, they just get stuck waiting forever for a response, though the error$ object returns “Error: login required”

I was able to resolve it by subscribing to the isAuthenticated$ observable before calling my initial APIs.

Some open questions:

  • Why does a failed HTTP get API cause the login to fail on reload, and only if cross-site tracking is disabled??
  • Should the HTTP request fail if there is an auth error applying the token?
  • If that isn’t possible, can the error message on the error$ object be any more descriptive about the context of the failure? Ideally, it would say it is a failure getting the token for the HttpInterceptor, and some information about the Http request. ‘Login required’ was confusing, because the login was successful (isAuthenticated$ was true).

This debug cycle was extremely painful, and anything that could help with tracking down such issues in the future would be great.

9

Hi @mayhew3,

I’m glad to hear you were able to isolate the issue. I’m sorry to hear it was so difficult to track down. I agree with you that it would be helpful to have more detailed errors than Login required. I am not sure what is causing the behavior related to the cross-site tracking setting. I will ask about this.

Also, it’d be great to get this feedback passed on to the product team via the feedback category:

10

Thanks, I’ll do that!
Cheers,
Mayhew

1 Like
11

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.