Improve OAuth 2.0 / OIDC Integration

[mraible]

This issue is to track the improvements needed to make the OAuth 2.0 / OIDC integration into a wonderful developer experience. The main PR has been merged, these are the items remaining:

• Exclude AngularJS as an option when oauth2 is authentication type
• Fix redirect to http://localhost:9000 when using yarn start - Add redirect-to-origin support to OIDC / OAuth 2.0 #6436
• Integrate it into the docker-compose sub-generator, using the Traefik PR as a reference. Start of PR here
• Add a specific documentation page, and add the new properties to http://www.jhipster.tech/common-application-properties/ (if needed, not sure if there are some)

@jdubois You mentioned here that documentation should be added in http://www.jhipster.tech/microservices-architecture/. However, I only verified this works in a monolith. I don't believe it will work in a microservices architecture. @danielpetisme created a PR to add microservices support.

[jdubois]

Oh I thought it would work with microservices :-(
But you made a good decision: let's start simple, and then improve, we'll have this later!

[jdubois]

@mraible I edited your "todo list" to add a new item on documentation

[mraible]

PR #6436 fixes the redirect to localhost:9000 issue.

[mraible]

@deepu105 Do you have any advice on how to default to Angular 4 and disable prompting when OAuth 2.0 is selected?

[mraible]

@jdubois For the docker-compose sub-generator, should I prompt to see if the user wants Keycloak, or just assume they do if authenticationType === "oauth2"? The reason I ask is because they might not need Keycloak if they've configured a different IdP for their app.

[deepu105]

@mraible i'll do that on master tomorrow

[jdubois]

@mraible

• for the docker-compose sub-generator: if they have selected authenticationType === "oauth2" yes you should add automatically the Docker Compose configuration for Keycloak (doesn't do much harm anyway). But yes don't hesitate to do some advertisement for Okta - at least on the documentation (I don't think anybody would use that feature without reading the documentation)
• then there is something I'm not sure I fully understand: do you store anything in the Servlet HttpSession? I know this is supposed to be stateful, but I don't find where it's done, is that automatic with Spring Security? Anyway, I'm wondering what happens when you scale your application: if you don't have HTTP session clustering, does it work? Otherwise, does it work out-of-the-box with our Hazelcast and Infinispan session clustering?

[deepu105]

@mraible i didn't disable prompting as I figured we would soon add React there anyway so I just removed Angular 1 from options when oauth selected, IMO its better as user wont be confused why the prompt didn't show up and in Oauth2 docs we need to say that Angular 1.x is not supported

[mraible]

then there is something I'm not sure I fully understand: do you store anything in the Servlet HttpSession? I know this is supposed to be stateful, but I don't find where it's done, is that automatic with Spring Security? Anyway, I'm wondering what happens when you scale your application: if you don't have HTTP session clustering, does it work? Otherwise, does it work out-of-the-box with our Hazelcast and Infinispan session clustering?

@jdubois The only thing I store in the session is the login-origin-uri for redirecting back to the correct location for the client in dev mode. All the rest is handled automatically by Spring Security. I'm guessing it'll work with Hazelcast and Infinispan for session clustering, but haven't tested.

[jdubois]

@mraible great, so this should be tested, but indeed that should be OK

[jdubois]

Closing this as it's all done