Hi,
after migrating from the oldest Auth0 model to the new application/API model, I created 2 different applications, one for my SPA and one for my mobile app. Notice that they are the same set of users and both the platforms serve a similar purpose. A side effect of this is that now the number of my active users, being accounted by “app”, have nearly duplicated. At the moment I am enjoying the free subscription, but once I’ll switch to the other subscriptions this may make a difference.
While I understand the reasons of pricing model in some large enterprise contexts, it seems to be a bit forced for my use case, where users access the same API, login using the same resource (the Universal Login / web page), and are the same users.
I am missing something? Can I use a single application for both the Mobile and SPA UIs (it seems I can setup all mobile related stuff from the advanced settings of the SPA app)?
Thanks!
@bragma there is nothing hard in auth0 that will prevent these from using the same application, however it is something I would strongly encourage against. The proper way to configure the applications is to create a unique client for each of your applications. This does impact your Monthly Active Users and as such pricing, but here are some benefits and reasons why we discourage client sharing between applications (not an exhaustive list just some things that come to mind):
-
Grant Types and Token Endpoint Authentication can be configured per application. Each application/client type should use a certain grant type for authenticating and authorizing your users: SPAs (Implicit Grant), Native Applications (Authorization Code + PKCE and optional Refresh Token), Regular Web Apps (Authorization Code with authenticated token endpoint, Optional Refresh Token, and Option Client Credential), Non-Interactive (Client Credential).
-
Token issuance of id_token will be intended to be consumed by the client (aud claim is client_id).
-
SPAs and other browser based applications will get different expiration policies from non-browser based clients for the access_token.
-
Each application has a different threat model for the environment in which it runs. By configuring a unique client for each of your applications you can tighten up your configuration to meet the runtime environment of your application (tied closely to #1).
-
Sharing a single client will impact the authorization grant created for each application and the tokens issued will share the same authorization policy. This violated Principal of Least Priv.
There are some additional reasons to have a 1…1 relationship between auth0 client and your applications.
@sgmeyer thanks for your prompt answer. I agree to the technicalities you explained, even though considering the costs it may in some cases be worth the consequences. Since more and more people will move to the new model, and suddenly discover they have doubled the number of users, will your pricing plans take this into account? Thanks!
@bragma I am not aware of any pricing updates coming to redefine an MAU, but I will do some internal digging. If I find anything new I’ll report back here.
Apologies if I am missing something, can you please elaborate a bit on what you mean by new mode? In our old model, before we introduced APIs/Resource Servers we still recommended each application get its own client. The main change here was now, instead of modeling Resource Servers and APIs as a client they should be modeled as the API/Resource Server construct which is not considered in MAUs.
I am an old time user of Auth0 so some time passed and I may be wrong, but if I remember correctly at the beginning there were no apps or API but only clients and the client type was just purely cosmetic or non existing. In any case, thanks for the answers and please consider if the question regarding same users, different apps may make any sense in your pricing policies.
I’d really like to thank you for the new pricing model based on users only and not breaking them down to separate apps. This totally solved my question above. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.