Failed Silent auth (Chrome v80)

Hi,

After spending a long time debugging an app I recently created and added authentication based on Auth0 using github.com / Swizec / useAuth (A react library which eases using auth0-js) I realised that in Chrome I was losing the session after reload.

The library specifically warns about this: github com / Swizec / useAuth#persisting-login-after-refresh

but I double checked all auth0 configuration and the fact that it is working fine in Chrome makes me suspect recent security features in later versions of Chrome.

This issue is happening in my app in Chrome (and in incognito mode so it doesn’t appear to be any plugins), but not FF (neither in private window mode).

So I tried the example app (useAuth):

https gatsby-useauth-example . now . sh

It works and retains the session in Safari v13.1 (14609.1.20.111.8) but session is lost in Chrome v80.0.3987.163 (and weirdly and in opposition to experience with my in FF v68.5.0esr) upon reloading after logging in.

In the auth0 logs, it is very clear the issue is due to slient auth failure:

Here is an example of the failure in chrome:

{

“date”: “2020-04-10T06:40:30.707Z”,
“type”: “fsa”,
“description”: “Login required”,
“client_id”: “77jh2jfcpuYdRkdbnYPAh44DZgWsmCiw”,
“client_name”: “Xorodia”,
“ip”: “84.76.183.234”,
“user_agent”: “Chrome 80.0.3987 / Mac OS X 10.14.6”,
“details”: {
“body”: {},
“qs”: {
“client_id”: “77jh2jfcpuYdRkdbnYPAh44DZgWsmCiw”,
“response_type”: “token id_token”,
“redirect_uri”: “http : / / localhost:8910 / auth0_callback”,
“scope”: “openid profile email”,
“audience”: “https : // dev-8pnznm20 . eu . auth0 . com / api / v2/”,
“state”: “nCEeyZN6U2dVN8RwQ6VAJmtYNyT7G7gh”,
“nonce”: “HOjsQIlu-Bfa8ge~Idg_g76~QEU2RmOK”,
“response_mode”: “web_message”,
“prompt”: “none”,
“auth0Client”: “eyJuYW1lIjoiYXV0aDAuanMiLCJ2ZXJzaW9uIjoiOS4xMy4xIn0=”
},
“connection”: null,
“error”: {
“message”: “Login required”,
“oauthError”: “login_required”,
“type”: “oauth-authorization”
}
},
“hostname”: “dev-8pnznm20.eu.auth0.com”,
“audience”: “https : / / dev-8pnznm20 . eu . auth0 . com / api / v2 /”,
“scope”: [
“openid”,
“profile”,
“email”
],
“auth0_client”: {
“name”: “auth0.js”,
“version”: “9.13.1”
},
“log_id”: “90020200410064032150004638802037372954393785399917936674”,
“_id”: “90020200410064032150004638802037372954393785399917936674”,
“isMobile”: false
}

and of success in FF:

{

“date”: “2020-04-10T06:48:14.632Z”,
“type”: “ssa”,
“client_id”: “77jh2jfcpuYdRkdbnYPAh44DZgWsmCiw”,
“client_name”: “Xorodia”,
“ip”: “84.76.183.234”,
“user_agent”: “Firefox 68.0.0 / Mac OS X 10.14.0”,
“details”: {
“prompts”: [],
“completedAt”: 1586501294631,
“elapsedTime”: null,
“session_id”: “ZKw2yX6wTx1lTlZ1w4yVYrU22Dj-ZUe5”,
“device_id”: “v0:3c27a9a0-79e7-11ea-97b9-a7a5d5759cd7”
},
“hostname”: “dev-8pnznm20 . eu . auth0 . com”,
“session_connection”: “Username-Password-Authentication”,
“user_id”: “auth0|5e8e4ea863116d0c00a75368”,
“user_name”: “saimonmoore @ gmail.com”,
“auth0_client”: {
“name”: “auth0.js”,
“version”: “9.13.1”
},
“log_id”: “90020200410064816216000729706101051814883897568581910546”,
“_id”: “90020200410064816216000729706101051814883897568581910546”,
“isMobile”: false,
“description”: “Successful silent authentication”
}

I’m on (OSX Mojave 10.14.6)

When I compare the cookies you can see a different set of cookies in each browser:

Chrome:

FF:

I also generated HAR files both for the example app and my own:

xorodiaChromev80.har (5.6 MB) xorodiaFirefoxv67.har (170.1 KB) gatsby-useauth-example.now.shFirefoxv67.har (213.4 KB) gatsby-useauth-example.now.shChromev80.har (7.7 MB)

Hi @registrations,

Welcome to Community!

Silent auth uses a cookie session, so it is likely not getting the cookie (or the right cookie) for some reason. Are you using the most recent version of auth0.js?

Just because I am curious, why did you choose this repo vs the Auth0 supported React quickstart.

We have since come out with a new SPA sdk, auth0-spa-js, and typically recommend using that unless you have a specific reason to stick with auth0.js.

Let me know,
Dan

Hi Dan,

Yeah I’m guessing it’s to do with the session cookies but lost right now debugging this issue.

I basically chose useAuth because it does a whole lot of the heavy lifting & boilerplate that auth0.js (and the tutorial you linked to using auth-spa-js). If you look at what useAuth does, you can see it’s very very easy to setup auth and to be honest I’d rather be concentrating on the business logic so that’s why I went for it (another reason is that a friend recommended it).

Can you point me in the right direction to further debug this?

Regards,

Saimon

Here are a few strategies to debug:

  • Start up the react quickstart I linked and see if it is causing the same error.
  • DM me a HAR file of the failed transaction
  • As I mentioned, using the most recent version on the SDK is important, as Chrome rolled out changes to cookies recently. This would be the first, most obvious thing.

Could you expand on this? I can pass this feedback on to the team to improve your developer experience.

Let me know,
Dan

I am also using this library in my own app.

The reason I chose to use it is that I am using Hasura and I require the accessToken to pass as a header. I couldn’t see anyway to access the accessToken (instead of the idToken) through the auth0-spa-js library. Additionally, when running on localhost I couldn’t get the auth0-spa-js app to give me anything at all!

I looked online and people recommended setting up your hosts file and a local server to enable SSL. Quite frankly that was too much effort when I was just starting (and probably ever, I’m very lazy)

I am also encountering the same issue (I think) as OP however in my case I only lose the session on refresh when the user is logging in with Google. Any ideas?

Did you look at the docs? It couldn’t be much more straightforward. Call auth0.getTokenSilently().

Here is an example, with code, of how to call an API with the access token as the header.

You can develop on localhost, there are certain caveats like not being able to skip a consent dialogue but you can easily boot up a react app and get the tokens and make calls.

Yep, so my hang up is when getTokenSilently doesn’t work on local host.

Having to setup a separate path for dev and confirming this pop up every time I wanted to make a request just didn’t appeal for two reasons.

  1. It is a bit messy to setup all this dev only code. I could call it once on dev, save the token and then proxy calls but…
  2. I want to be developing the same stuff I intend to deploy.

I just booted up the react quickstart and silent auth is working fine on LH with chrome v80.

I can help with your issues, but you have to give me more than “it doesn’t work”.

Any errors? It can be helpful to share some code. How about your config?

It should only occur on first login. Not sure how you would be avoiding this using the swizec example, as LH can never be a verifyable first party app.

+1

From what you’re saying it sounds like I’ve got the wrong end of the stick.

I’ll admit I followed the tutorial from Hasura rather than the one you linked above.

Just to confirm:

  1. Calling “getTokenSilently” should work on localhost? When I did this I either got nothing (no error, nothing, it was very weird) or a short random string.
  2. When developing locally, you have to show a consent dialogue, but only once per session?

I will have a go this weekend at using auth0-spa-js again based on your feedback using the instructions you provided.

1 Like

Absolutely. If you want to try and debug this, boot up a quickstart which should take less than 5 minutes and see if you can log in and refresh the page. This will signal that the app is using silent auth to get a new token after refresh.

The short random string is an opaque access token designated for the /userinfo endpoint.

Even if you clear the cookies/logout you shouldn’t have to do it again.

I suspect I was not correctly defining the audience :slight_smile: Thank you for your patience. I’ll report back this weekend (hopefully with success)!

1 Like

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