Auth0 Lock 10.19 always prompts for consent page despite allowing for skipping consent

Help
, ,
1

We are currently developing a SPA in React with Auth0 Lock v10.19 and experienceing the following issue when using the implicit grant flow with an API:
Despite setting “Allow skipping Consent” to true as well as not having localhost in the callback URLS and our client being listed as first party in the Auth0 management API
the Auth0 Consent Page always pops up! (tried it also with both actived and deactivated OICD-conformant settings ).
Here are our Lock Settings:

lockOptions = {
            languageDictionary: {
                title: "MidnightDeal"
            },
            theme: {
                logo: 'img/icon.jpg',
                primaryColor: '#000000'
            },
            oidcConformant: true,
            autoclose: true,
            auth: {
           
                params: {
                    audience: 'https://midnightdeal.at',
                    scope: 'openid read:midnightdeal',
                }

and the jwt that we get returned:

{
  "iss": "https://midnightdeal.eu.auth0.com/",
  "sub": "facebook|10207297312865215",
  "aud": 
    "https://midnightdeal.at",
    "https://midnightdeal.eu.auth0.com/userinfo"
  ],
  "azp": "rR2MRm8YubY4kpQIThlvXHAG3RjoFTAK",
  "exp": 1501818635,
  "iat": 1501811435,
  "scope": "openid read:midnightdeal"
}
2

https://midnightdeal.at is our API btw

3

From the conditions that might trigger this behavior the most easy to miss is the first party one as that is still not being surfaced through the Dashboard so I’ll focus on that one. You say you verified this through the Management API; was there any chance that you used the get all clients endpoints and saw the first party flag on a different client?

Personally, I would just issue a PATCH /api/v2/clients/{id} request with a payload like this { "is_first_party": true } . If this was not the source of the issue then this request would be a no-op so no impact and this way you know for sure that the client will now be identified correctly as first party.

4

Thanks so much for that! Patched it and it works - even though I doublechecked again and it was listed as first Party:P

5

Thanks so much for that! Patched it and it works - even though I doublechecked again and it was listed as first Party:P

6

Do you by coincidence know, why the rememberlastlogin property in an OICD-conformant pathway is disabled? Is it temporary or due to OICD specifications?
Cheers