Hi, i realized the third party apps are less restrictive than first party:
all third party apps are allowed to use all the connections promoted to domain level. In opposite to the first party, where they specifically need to be activated to use each connection by adding “enabled_clients” to the connection list.
This is very undesired as im forced to promote the connection to allow a third party app to use it, but then it will be enabled to every 3rd party and i lose the fine-grained control.
A bit of debugging at the browser (using universal-login + Lock) shows the third party apps need to declare __useTenantInfo: true in order to get all the domain level connections, but this practice is actually bypassing the enabled_clients declared for every connection.
The first party apps expose an endpoint at https://cdn.auth0.com/client/<client_id> which returns all the client info, including the enabled connections.
Security wise, could i create a first-party app for a third party company using my connections and my APIs?
please clarify this on the docs, and provide a clear difference between these apps.
Hi Rodrigo.
In general, if you are finding that different third-party applications need different connections enabled, this might be an indication that you need separate Auth0 tenants. One could argue that this could be the case for first-party app as well, but the many-to-many relationship between apps and connections is preserved for historical/compatibility reasons.
Maybe if you want to explain a clear case for which you need finer control in enabled connections for third-party apps, we can discuss the specific use case.
Security wise, could i create a first-party app for a third party company using my connections and my APIs?
No. If an external company owns the application that connects to your API, you should create a third-party app. This way you guarantee that the consent screen is always shown to the user (something to the effect of “do you want to allow this third-party app to access your data?”).
These are the main differences for 3rd party apps:
Consent screen is always displayed.
Connections are handled differently (domain connections)
They can’t request tokens for management API v1.
Available grant types are restricted (no resource owner password grant)
There could be more in the future (e.g. more stringent security measures like shorter sessions or tokens, fewer claims about the user in tokens) so it’s important to choose the appropriate type.
Hope that helps a bit. I will try to add these to the documentation, thanks for the feedback!
Nicolas, thanks for a very detailed reply about my question!
I will address this control by rules, and create 3P apps only by the adm API instead of the oidc endpoint, in order to better control the applications.
