Is it a good practice to separate the authentication server from the resource server?

Question

As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.

I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.

With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.

Is this approach sound?

Answer 1

If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.

Generally its no recommended to build one by yourself.

Store your users in a database table.

Authentication using other sites problems:

Your visitor may not want to have an account with 3rd party site.

It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).

Answer 2

It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).

In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).