We Keep Coding

which oauth2 flow do I need for multiple domain with a custom login screen

I'm implementing an authentication and authorization mechanism to unify login mechanism's across three different websites using an external identity provider and OAuth2.
The requirements that are causing design implications.
- Users and permissions managed externally to the existing websites in an external identity provider.
- The user should only have to log in once.
- The login screen needs to be embedded in our application rather than using an identity providers.
I'm creating a login web application. I'm not sure which OAuth2 flow to use. I've used the Authorization code flow previously with Spring security, but that seems to need an external identity provider's login form.
Should I use the implicit flow directly from the login site's javascript? How concerned do I need to be that it's not as secure as the code flow.
Do I need to handroll a solution to call an idp's sdk to get tokens and then sling them into http headers for subsequent use by the other domains Presumably CORS will be an issue? I'll need to include the id token for the other domain to know which user it is - is it secure to pass around the id token via the resource user's browser.
thanks for any guidance, as you can tell its a bit of a muddle in my mind!

Email & password authentication with control over who can create a account

I'm looking for some advice about how to execute a authentication implementation on my web application with some specific requirements.
The web application consists of a angular frontend and a spring-boot backend. All of this is hosted on Google Appengine and I’m using Google Cloud Datastore for the database.
I want to implement some kind of authentication system now where the user uses email and password to log in. The users should only be able to create accounts if I have allowed that email to register. What would be the best way to implement a system that achieves this?
I’ve been looking at Firebase for the authentication part and that looks good but how do I integrate this with spring boot to limit access to the site depending on if the user is logged in or not?
Another question is about the create user requirement. Would a good solution to this be to store emails that are allowed to register in my database, and then check every time someone wants to register if their email is in there before using Firebase to create that user?
I'm not very experienced with authentication implementations so any advice is appreciated.

I think that Spring Security + Stormpath its a good choice. Here is one nice tutorial: https://scotch.io/tutorials/build-a-spring-boot-app-with-user-authentication
And about the registration permission for enabled emails you should really store on DB to have control over it, I dont see any problem with that.

Building a Java OAuth2.0 authorization server with Keycloak

TL;DR
Objective: Java authorization server:
OAuth2.0 authorization code grant flow with fine-grained permissions (not a mere SSO server)
User management and authentication: custom database
Client management and authentication: Keycloak
Questions: What are the best practices for implementing a Java authorization server with applicative permissions handling backed on Keycloak?
What Keycloak adapter/API should I use in my development?
How should the users be managed/appear in Keycloak if they are to appear at all?
Forewarning
I am quite the beginner with Keycloak and, though I think I understand the main principles, it seems to be a rich tool and I fear I may still be mistaken about some aspects of the best ways to use it. Please do not hesitate to correct me.
Context
We are looking at implementing an API requiring our users (henceforth "users") to grant permissions to third party applications (henceforth "clients").
Our users are stored in a custom existing database-based user management system. As for our clients, we are thinking of using Keycloak.
The users consent will be given using an OAuth2.0 Authorization code grant flow. They will log in, specify which permissions they grant and which they deny, and the client then retrieves the access token it will use to access the API.
It is my understanding that Keycloak can handle the authorization token but it should not know anything applicative, which our permissions are. As a consequence, I thought of building a custom authorization server which will use Keycloak for all identity/authentication problems but will handle the applicative permissions by itself.
Then, we will use Keycloak for client authentication and authorization code/access token management, and an applicative part will check the permissions.
Problem
Besides my first experimenting, I've been roaming the Internet for a week now and I'm surprised as I thought this would be quite a standard case. Yet I found next-to-nothing, so maybe I'm not searching correctly.
I've found many Spring/Spring Boot tutorials1 on how to make a "simple authorization server". Those are mainly SSO servers though, and few do manage permissions, with the exception of those mentioned in this SO answer2. That I think we can deal with.
The real problem I have, and that none of the tutorials I have found are treating, is the following:
How do I integrate Keycloak in this authorization server?
I've been having a look at the available Java Adapters. They look OK when it comes to authenticate but I did not see hints about how to manage clients from a custom authorization server (ie administer the realm).
I therefore suppose I should use the admin API. Am I correct and is it good practice? I saw no adapter for that, so I suppose I should then use the REST API.
I also wonder how we should integrate our users in design? Should they be duplicated inside Keycloak? In this case, should we use Keycloak's admin API to push the data from the authorization server or is there a better way?
Finally, am I missing some other obvious point?
Sorry for the long message and the many questions, but it all boils down to one question in the end:
What are the best practices when building an authorization server using Keycloak as a backbone?
1. Some examples:
Spring Boot OAuth2 tutorial -
A blog post -
Another blog post
2. I've mainly focused on the sample app provided by Spring Security OAuth

Building Java OAuth2.0 authorization server with Keycloak
This is possible but is bit tricky and there is lot of thing which needs to be customised.
You can derive some motivation from below repo.
keycloak-delegate-authn-consent
Building custom Java OAuth2.0 authorization server with MITREid
If you are open to use other implementations of Oauth and OIDC,I can suggest you MITREid which is referrence implementation of OIDC and could be customized to a great deal.Below is the link to its repo and its open source.
I myself used this to requirement similar to yours and it is highly customizable and easy to implement.
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
MITREid Connect uses Spring Security for its authentication, so you can put whatever component you like into that space. There are lots of good resources on the web about how to write and configure Spring Security filters for custom authentication mechanisms.
You'll want to look at the user-context.xml file for where the user authentication is defined. In the core project this is a simple username/password field against a local database. In others like the LDAP overlay project, this connects to an LDAP server. In some systems, like MIT's "oidc.mit.edu" server, there are actually a handful of different authentication mechanisms that can be used in parallel: LDAP, kerberos, and certificates in that case.
Note that in all cases, you'll still need to have access to a UserInfo data store somewhere. This can be sourced from the database, from LDAP, or from something else, but it needs to be available for each logged in user.
The MITREid Connect server can function as an OpenID Connect Identity Provider (IdP) and an OAuth 2.0 Authorization Server (AS) simultaneously. The server is a Spring application and its configuration files are found in openid-connect-server-webapp/src/main/webapp/WEB-INF/ and end in .xml. The configuration has been split into multiple .xml files to facilitate overrides and custom configuration.

Java authenticate user within a different domain.

I'm building a single signon app and I'm wondering if it's possible to authenticate a user within a completely different website without using oauth, "not a possible solution". I'm currently able to do this by copying the other websites login form into my page along with the post url, hidden field, username/password field. I would much rather do this behind the scenes if possible where credentials wouldn't be exposed. I'm wondering if something like httpclient would be able to accomplish this task.
Any suggestions would be appreciated.

Yes, this is theoretically possible. You are trying to use the other web site as an authentication provider. You need to find out what authentication services the other website offers - you could try federated authentication, LDAP-based authn, kerberos, etc., but if the site you want to authenticate to doesn't support any of these, then you aren't going use any of these protocols.

SSO via encrypted token

We have the need in a project to implement single sign-on for two different web applications, one being our own and one is implemented by someone else. For our own application we have user/password stored (encrypted) in the database. Since our application will be integrated in their environment, we now need a mechanism to let us authorize the user already being logged in at their side without showing a login screen again.
Since I'm not a security expert myself, I started reading (on a high-level) about a few techniques regarding SSO, e.g. OpenID, Kerberos, SAML, CAS - but I have not yet gained practical experience.
Before marching in the wrong direction - can someone provide me with own experience in that field and point me to a framework to use or a good (and recent) article about how this should be done?
One more infomation: The customer talks about preferring to pass encrypted tokens between the two webapps. Does this make sense? And does this lead to a certain technique?

We use a SAML realization for this purpose ( https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/index.html ) - it was easily integrated inside our existing web applications.
The working scheme can look like as follows: you will have a login page, where the SAML framework redirects user. so, after successful login, he got a cookie with the auth token, and redirected back to the web application page. you will also have an identification webservice, which you can call, passing the token provided, and be able to get the auth credentials (user role, etc) from there, so all your web applications can identify this user as logged in.