As it turns out, it's sort of a combination of the Authorization flow and the Implicit flow. The Implicit flow is for client-based applications, and the authorization flow allows for server-to-server access, I think.
What ended up being the right answer is retrieving an access_code from Google, with a specific audience specified. The audience is the client_id of my web application. The access_code is then given to the web application to authenticate my client (be it browser or mobile app). The web application exchanges the access_code for an id_token and a refresh_token using the Google token endpoint. Then these tokens are verified and used to authenticate subsequent requests.
From there the user identity is authenticated, and it's up to me how I'd like to handle that - be it token-based authentication for the native mobile app or cookie authentication for the browser.
Disclosure: I'm an engineer at Auth0.
It depends on one major point... you need to decide if:
- you want to directly spend a considerable amount of time (and indirectly spend money) on building and/or maintaining your own identity provider and authorization server
- or you prefer to directly spend money and use a third-party authentication provider like Auth0.
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
Applications often rely on user databases for authentication. Auth0 enables you to easily connect to these repositories and use them as identity providers while preserving user credentials and providing many additional features.
(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
Auth0 supports the automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time.
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.
Best Answer
Spring cloud provides already this behavior. Just add different Clients. Like iosAppClient, androidAppClient in your AuthorizationServerConfiguration class.
In the backend you can get the clientID like the following
and implement different behavior based on the clientId.