I currently have a 15 year old legacy monolithic webapp with close to 1 million users, using a home-grown authorization & authentication system: JAAS, user names & pwds store in a DB with basic password hashing, some 2FA personal verification questions (with different hashing algorithms, etc).
I will be overhauling the application over the next 12-18 months, primarily focused on the UI, but slowly upgrading the underlying parts as well (upgrading to Spring, Spring Security, etc). Within this project, we've decided to tackle the UI upgrade on a module-by-module basis; making each module available once it is complete; a perfect opportunity to break the monolith into individual webapps (all maintaining the same UX design).
Where I am stuck trying to plan this out is at the authentication & authorization level. I need a cross-cutting solution that will arc over all the modules, so that when a user is directed from one webapp to another, it is a seamless transition – they won't even know they are on different webapps. OAuth2 sounds like the perfect solution.
I'm stuck trying to understand how to integrate this. Do I have to build my own custom OAuth2 server? That hits me like a terrible idea. But how do I:
- migrate all my user accounts & authorization process to a 3rd party OAuth2 server
- customize the look & feel to match the rest of my application (not sure how easily/likely this will be)
- prevent the typical "Application XYZ would like permission to access your account…" popup when connecting via a 3rd party server? (ex: Google OpenID, Facebook, etc).
My goal is to provide a seamless transition for the user from the current state to the new state, but providing the ability to create separate webapps that all authenticate & authorize outside the webapp.
Best Answer
Disclosure: I'm an engineer at Auth0.
It depends on one major point... you need to decide if:
Both options are perfectly viable from the point of view of your functional requirements. With custom development you are in full control of the functionality you decide to support so I'll focus part of the answer on how Auth0 can respond to the requirements you listed.
However, before moving into that, no matter your decision, for authentication you should focus on OpenID Connect instead of OAuth2. The latter will be more applicable if you plan to also have API's in the mix and not just split the monolith into separate web applications.
How to migrate existing users to an Auth0 based system?
You can either decide on keep using your database and rely on Auth0 to provide all the compliance with the authentication related protocols you may need to use or you can migrate your users to Auth0 managed databases and stop worrying about how you store and validate passwords.
If you prefer to keep using your database, see Authenticate Users with Username and Password using a Custom Database
(The docs refer to MySQL just as an example, other database engines are supported)
On the other hand, you can seamlessly move user credentials to Auth0 databases by leveraging the migration process described in Migrate Users to Auth0
You can also create all your users in Auth0 through the Management API if you prefer for all of them to start use our password hashing algorithm at once. This has the side-effect of requiring users to reset their password.
How to keep using custom two-step authentication (verification questions)?
The authentication pipeline provided by Auth0 is fully customizable through the use of rules. This means that even though you didn't have to implement any protocol related stuff you can still fine-tune the small details of how authentication happens in your application.
This includes the possibility of continuing to use your existing verification questions as a way to do a two-step authentication process where the user provides an initial password verified by Auth0 and then you ask them for further information from a custom rule. (rules are just Javascript so the possibilities are infinite)
However you can also decide to drop the verification questions and instead go with Auth0 Guardian as a way to increase the security of the authentication process.
How to customize the look and feel of the authentication UI?
With Auth0 you can have a clean authentication UI in no time by leveraging the default login pages or authentication widgets like Lock. All of these support some degree of customization and you can always decide to do your own UI yourself and instead leverage the lower level Auth0 libraries (Auth0.js) that make no constraints on the user interface.
For more information on customization:
How to prevent explicit consent pages?
You can use Auth0 both as an identity provider for authentication purposes and also as an OAuth2 authorization server (currently available only in US region) for your API's.
As an identity provider you don't have to worry about consent pages, user authenticates with their credentials managed by Auth0 and then gets redirected to your application - that's it.
In the OAuth2 as a service scenario when consent is enabled the road-map includes allowing to bypass consent pages for certain applications.
On a final note, that seems like a very interesting and challenging project that you got there, so best of luck independently of your final decision.
I already went through something similar on a previous job when I had to re-implement the authentication system of a legacy application. We implemented our own identity provider and authorization server and to be honest I still have the feeling that we may have forgot something really essential.
I think that's the biggest issue with rolling your own security, there will be occasions that deadlines impose shortcuts and security is not really a good area to make shortcuts.
If you have further questions let me know if you think I may be helpful.