jhipster 2 : What is the difference between the authentication option? - spring

I have updated the jhipster generator from version 1 to version 2. In the previous version we had to choices of authentication when generating a new project. We had the choice between Cookie authentication and Token authentication (with OAuth). This was very clear for me. But in version 2.1.1, we have now three choices :
1 > HTTP Session Authentication (stateful, default Spring Security mechanism)
2 > OAuth2 Authentication (stateless, with an OAuth2 server implementation)
3 > Token-based authentication (stateless, with a token)
I want to used the authentication both for web and mobile app (ionic-framework), which one to one between 2 and 3 ? Is this choice make my app scalable using clusters ?
Thanks

you will the basic info about jhipster authentication type here
http://jhipster.github.io/security/
from my personal experience in ionic-framework working with REST api of jhipster, I can say that don't use HTTP Session Authentication for mobile app (ionic-framework) because mobile apps don not play along with cookies in general which HTTP Session Authentication depends upon.
Both Oauth2 and JWT work fine with ionic hybrid app
HTTP Session Authentication
This is the "classical" Spring Security authentication mechanism, but we have improved it quite significantly. It uses the HTTP Session, so it is a stateful mechanism: if you plan to scale your application on multiple servers, you need to have a load balancer with sticky sessions so that each user stays on the same server.
OAuth2 Authentication
OAuth2 is a stateless security mechanism, so you might prefer it if you want to scale your application across several machines. Spring Security provides an OAuth2 implementation, which we have configured for you.
The biggest issue with OAuth2 is that requires to have several database tables in order to store its security tokens. If you are using an SQL database, we provide the necessary Liquibase changlog so that those tables are automatically created for you.
As Spring Security only supports OAuth2 with SQL databases, we have also implemented our own MongoDB version. We generate for you all the OAuth2 implementation for MongoDB, as well as the necessary MongoDB configuration.
This solution uses a secret key, which should be configured in your application.yml file, as the "authentication.oauth.secret" property.
JWT authentication
JSON Web Token (JWT) authentication, like OAuth2, is a stateless security mechanism, so it's another good option if you want to scale on several different servers.
This authentication mechanism doesn't exist by default with Spring Security, it's a JHipster-specific integration of the Java JWT project. It is easier to use and implement than OAuth2, as it does not require a persistence mechanism, so it works on all SQL and NoSQL options.
This solution uses a secure token that holds the user's login name and authorities. As the token is signed, it cannot be altered by a user.
The secret key should be configured in the application.yml file, as the jhipster.security.authentication.jwt.secret property.

Related

Understanding security mechanisms of JHipster: When to use JWT, HTTP Session or OAuth2 and OpenID Connect?

I'm creating a monolithic application (something like a e-commerce or a marketplace) and I'm concerned that it is secure. I understand (broadly speaking) how JWT works, but not sure about HTTP Session or OAuth2 and OpenID Connect.
When is it advisable to use each of these options?
For a monolith, I would rather recommend HTTP session over JHipster's JWT implementation because it's more secure: on client, it uses an http-only secure cookie while JWT is stored in browser's LocalStorage. If you want to scale horizontally your monolith by running multiple instances, you will have to manage session replication but Spring does it well. HTTP session is well known and described in Spring Security docs.
OAuth2 and OpenID Connect is better when you want to authenticate against other identity providers like Google, Facebook, ... It makes also more sense in the context of a microservices architecture.

custom oidc in keycloak

I have a spring based application which does authentication and authorization(oauth2 based) for a client app.I want to now use keycloak to manage my authorizations, but i want to keep my spring code. Basically i want to use my existing auth code as an external identity provider in keycloak.
I am thinking of adding changes in client app such that it receives token from my existing oauth code(which does the authentication) and then exchange this token with keycloak(for session and authorization management). How can i do this? What configurations need to be done in keycloak?
I read about token exchange in keycloak here, but i am not clear about the kind of token i need to send from my existing auth code.
https://www.keycloak.org/docs/latest/securing_apps/
Here is how OAuth2 roles are usually spread:
Keycloak is authorization-server
Spring service is resource-server
front-end is client
user is resource-owner
I have a doubt of you wanting your Spring service to be "authorization-server" as well (serve user identity). If so, I think you should not.
Keycloak (or any other OpenID provider) should be the only authorization-server. Both Spring and client(s) should be configured to use it as so.
To write it differently, Keycloak is responsible for users login and emitting tokens with user ID (subject) and rights (roles or whatever). Other tiers in the architecture (clients & resource servers) get user info from the token and apply relevant security checks (spring security annotations, Angular guards, etc.).
I published a mono-repo for a meetup with minimal sample involving a Spring resource-server and Angular (with Ionic) client talking to a Keycloak OpenID authorization-server. You might find some inspiration browsing it.

Resource Owner Password Credentials with Spring Boot

I have a legacy desktop application that communicates with a Spring Boot server (latest version 2.2.2.RELEASE). I'm using OAuth2 for authentication (provided by spring-boot-starter-oauth2-client). I want to avoid changing the client because is a legacy application. It is capable of collecting the credentials and start the session via HTTP Basic Authentication, and then keep the cookies for the session in the following requests.
Given this scenario, I think best option is to make use the OAuth2 Resource Owner Password Credentials grant. With this, we can exchange the collected credentials by the OAuth2 Tokens. We have two options:
Option 1:
Modify the client application to use the access tokens via the Authorization header. This will require to make an initial call to the Authorization Provider to exchange the collected credentials by the tokens.
Option 2:
Keep using the Spring session and store the information about the OAuth client in the server.
I found this project ALMOST does that: https://github.com/jgrandja/spring-security-oauth-5-2-migrate. It has a client (messaging-client-password) defined with authorization-grant-type: password which will activate the OAuth2 Resource Owner Password Credentials grant in Spring Boot.
It creates an OAuth2 client and stores its information in the session, then Spring is able to use that client in further requests. The problem with this project is it seems to only work as when the OAuth client is used to make HTTP requests (e. g. an endpoint that makes a call to another service) and not provide authentication to the controller. You can find more information about this in here:
Spring Security 5.2 Password Flow
Github related issues: link1, link2, link3
Exception thrown when we try to use the password client as authentication
The natural idea to overcome this is to implement a proxy and use the OAuth2 client in the requests. Well, Spring already offers a proxy solution, the Spring Cloud Gateway. But I don't know to accomplish that with this setup.
Any insights? Am I thinking correctly or should I follow a different approach?

Spring Security OAuth - Can it consume JWT tokens from Keycloak

In Spring Security OAuth, can it consume/work with JWT tokens that were generated from a user authenticating with Keycloak? Keycloak's open-id far as that goes, but it all seems to be really similar. I'm still trying to understand the dividing line and also what's similar or same with this.
Basically I'd like to authenticate separately in a REST client then use the token in the Authorization header for REST calls to some web services. There seems to be some JWT stuff in in the Spring Security OAuth, so I'm wondering I can actually use that instead of the Keycloak Spring stuff? Are there any examples of this out there? (I'd love to use the Spring security checks on different methods in my controller)
You can use the Keycloak Spring adapter and still rely on Spring Security annotations for controller security. The main purpose of the Keycloak Spring adapter is simplify the integration with Keycloak for interactive login and also to correctly map JWT access token claims into the Spring Security authentication context.
Reading through the Spring Security OAuth2 documentation, I get the impression that it's not quite ready out of the box to handle OpenID Connect JWT access tokens. However, it's customizable so it could most likely be made to work.
My advice for now is to stick with the Keycloak Spring adapter if you're using Keycloak as your OIDC server. It will save you time and it's well tested with Keycloak.

spring cloud oauth sso without authorize step

I have a spring cloud oauth #EnableAuthorizationServer that uses a jpa backend to store the accounts. I also have a couple of different clients, a website, an intranet and a ionic mobile app.
all the clients have separate client credentials inline in the oauth config block.
i have then tried to use the spring cloud sso to not have to login again.
my problem is that I want to remove the authorize step since all my clients are known to me and i simply want the user to be logged in across all my apps.
is this possible with spring cloud sso?
The authorization happens on the authorization server (so nothing to do with Spring Cloud). A UserApprovalHandler would do what you need, but the default one should work if you just set autoapprove=true (or a pattern matching te scopes you want to auto approve) in the client details. (Assuming your auth server is Spring OAuth.)

Resources