I understand that the consent page is useful for a 3rd party client accessing an API I have configured, but I’m now developing a 1st party client and I still always see the consent page like this:
![Consent screen][1]
How can I disable this screen for my first party client?
Note: This toggle allows skipping consent for verifiable first party clients. If your client is hosted on localhost, Auth0 has no reason to believe that it’s truly a 1st party client as the user may be maliciously (or without their knowledge) running any client on the localhost. If you want to skip the consent page during development, you can setup a mapping in your hosts file to map localhost to app.local for example.
Note 2: At the time of writing this, if you use /userinfo only as your audience parameter or have an OIDC-conformant client (under advanced settings for a client), then you can’t easily customize skipping the consent page. This is something we’re working on.
If you are currently developing an application and would like to check the skipping you can always setup a custom host in /etc/hosts file on your operating system (this works on windows too!)
@menno.hamburg All clients created currently have an "is_first_party": true property (as you can see using the Management API v2). When I said “verifiable”, I only meant in terms of configuration - as long as a client with is_first_party set to true has a registered callback URL that is not localhost, you’ll be allowed to skip consent.
(Reasoning: If localhost is registered as a callback URL in a prod client mistakenly, we don’t want users to skip consent as they may be leaking their data to a malicious client.)
@amaan.cheval by now it seems there aren’t any problems anymore regarding the OIDC-conformant client constraint you were mentioning.
I just managed to skip consent dialog for such a client. It’s just important that your allowed callback URLs do not contain localhostat all.
How did you create the client you use? Could you try using our Management API v2 to check if the client has the is_first_party property set to true? I believe that’s your issue. If the property is missing, you can use API v2 to PATCH the client with that property.
If the client was created from the Dashboard, the property should be added by default.
P. S. You’re using the password-realm client grant type, which is turned off by default. More documentation here: Application Grant Types
You solved my problem. is_first_party wasn’t listed when using the Management API to get the client. I believe I used the dashboard to create the client, so that’s a bit odd.
Anyway, I PATCH’d the client with is_first_party and it works like a charm.
@amaan.cheval we can’t get this working for our client. I’ve followed all the steps here, is_first_party is set to true when I check using the Management API v2. We don’t have localhost as any of our callback urls anymore (we did before). And we’re not using an OIDC-conformant client either. Any ideas?
@amaan.cheval we can’t get this working for our client. I’ve followed all the steps here, is_first_party is set to true when I check using the Management API v2. We don’t have localhost as any of our callback urls anymore (we did before). And we’re not using an OIDC-conformant client either. Any ideas?