Auth0 Home Blog Docs

Suggested SSO implementation

api
sso
sso-integration
backend

#1

At my company, we want to include SSO between our 2 web-application (regular web + restful api).

Here is the scenario:

Web App A

This web app is developed using symfony and has:

  • backend panel for “manager” users
  • restful APIs for our “customer” mobile apps (android and iOS)

Web App B

This web app is developed using lift/scala and has:

  • frontend for customer
  • backend for “managers”
  • api for several clients

Right now these web apps are independent and works well.

Now, we want users of (A) to consume (via mobile apps and server-to-server) services of (B) and, in the future, vice-versa.

What’s the best approach to handle this using Auth0?

(For us it’s not a problem to bulk import and merge our existing users from the two web apps in Auth0)


#2

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.

System SYS-A

  • 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.

~

System SYS-B

  • Web application CLIENT-B - mapped to an Auth0 client application entity.
  • API 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 CLIENT-A calling 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.


#3