Separate application authentication server

One of the ways to simplify your application server is to use something similar to the following flow:

The application generates a hash and directs the user to the login server with this parameter and another token identifying itself ;
The login server requests and verifies the credentials of the user;

• If the user cancels or the credentials do not confirm after N times, the login server returns the user to the application without confirming the login OR

• Upon confirming credentials, the login server redirects the user back to the application with the user ID and a signed hash value stored by the parties involved.

You can do this in a relatively simple way, without worrying about OAuth and other protocols that are too poorly documented and too complex for the specific need.

Advantages of this solution:

• Portable - each part of the application can be split into several different machines;

• Little code needed;

• It works for one, two or two hundred applications, as many as needed;

• Scalable, because it does not depend on where each part of the system is running;

• Simple to manage, as the only information shared between the parties is the authenticated user, by returning a valid ID and signature.

Important Considerations

This is a general sketch , which makes sense in an environment not subject to external attacks, or extremely targeted information (not that the solution is not good, but it is only as good as your careful to plan the details). You have to assess the degree of security required for your application and decide whether to simplify or use any robust solution. The difficult thing is to separate robust solutions from the complicated ones.

The explanation has been simplified, just to give an overview. Each step has to be properly taken care of, and you should use a secure connection and have a separate token for each client application. If the connection is not secure, an extra step is required to get a "token " from the server.

Consider using the CAS Central Authentication Service

Basically, CAS is a Java application to which you delegate the authentication service. It integrates, for example, with Active Directory, thus allowing the user to use the same AD password for WEB applications (something interesting in the case of corporate applications).

I use CAS successfully in an application developed in Grails (Java web framework, based on Spring, Hibernate, etc.).

CAS runs on a server other than the applications. So, any application that needs authentication, we delegate the same to that CAS instance.

You can configure for authentication to happen with a database, via JDBC.

The CAS is the name of the protocol whose application has the same name. It is a single sign-on, which means that after logging on to one application, the others that are opened within the same browser session will share their credentials, not re-prompting for username and password.

See on the CAS page that there are clients in Java, PHP, .NET, etc.