You start by mentioning SSO, but then you mention that what you really want is to consume services. In general, SSO means user authenticates into Application X by providing their credentials, then goes to Application Y and without having to provide their credentials again is already authenticated in Y with the same user identity as in X.
Nowhere in the above process the user authenticates directly to API’s, it’s mostly a client application thing.
If you want to have API’s that are decoupled from a single client application and can be called by multiple client applications then you need to treat them as first-class entities and not associated with a particular client application.
Based on the information you provided (which may be insufficient for me to provide a definitive answer) I would consider having the following.
- Web application
CLIENT-A - mapped to an Auth0 client application entity.
- RESTful API
API-A - mapped to an Auth0 API entity.
Customer mobile applications - mapped to Auth0 client applications; if they are indeed developed by third-parties you may consider them treating as such.
- Web application
CLIENT-B - mapped to an Auth0 client application entity.
API-B - mapped to an Auth0 API entity.
By treating the API’s as independent entities, you don’t actually need to have SSO in order to have
API-B. The client application would just request as part of the initial authentication request that an access token valid to call
API-B to be issued.
The above, is a simplified view, you would probably want to restrict access to certain API’s to only specific clients or to only certain users that have the necessary permissions. For user-level restriction you can implement that policy through rules while for server to server calls (aka client credentials) you could do so by configuration at the API entity.
Check the reference docs for more about API authorization related functionality.