Understanding HTTP Session security mechanism in JHipster - csrf

I am trying to figure out how the JHipster uses HTTP session for securing application and logging the user.
So far I’ve managed to understand the flow like this:
1) on landing page home.component sends request to api/account
with session cookies (if there are ones)
if there is a valid session >> uses credentials from stored cookies and then login the user
if no >> backend server responds HTTP 401 and sends XSRF cookie in response
As I understand responsible for this is Spring Security
2) when there was no acitve session we can fill the login form and log in
that sends request to api/authentication (XSRF cookie from step 1 required)
if all ok >> responds HTTP 200 and sends new XSRF cookie
if no >> HTTP 403 and sends new XSRF cookie
3) when step 2 is successful then frontend sends credentials from login form to api/account
one more time Spring Security checks XSRF cookie value (from step 2 this time)
if all ok >> business logic for log in the user is invoked
But in all these steps we need to intercept the cookies sent by backend and send them back to be able to pass through CSRF protection. Which part of JHipster project is responsible for that? Does it use webpack/browsersync or there is some Angular code created by JHipster which I am missing?
EDIT
My problem appeared when I've made a lot of changes to generated project as I want to use custom templates/styling and the services generated by JHipster. I've linked the templates with jhipster services.
When I try to log in the user I get in spring console output like this:
Forbidden: Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-XSRF-TOKEN'
From previuos request to api/authentication I get response with
Set-Cookie: XSRF-TOKEN=a129cb47-ec96-47be-aaae-69f90848c466; path=/
in browser network.
So it sets the cookie with wrong name I guess. I've change the cookie name manually in browser to: X-XSRF-TOKEN and resent the request. The new error looks like this:
Forbidden: Could not verify the provided CSRF token because your session was not found.
I don't understand the flow enough so I can't spot where is the problem. Maybe I've messed up and maybe there is some code generated by JHipster which is responsible for that. There are some classes in JHipster Angular frontend like StateStorageService. Do they take part in my problem or they are irrelevant to that issue?

I was facing the same issue while connecting a mobile app to the backend of spring boot. So basically angular has a method under the core functionalities called interceptors. Under the interceptors the response is gather and X-XSRF-TOKEN is captured and updated in Browser Cookie or in my case Ionic Local Storage as Cookie.

Related

FARM Stack - SameSite="none"; Secure can't be set on logout API call

I have a backend based on the FARM stack by MongoDB (https://www.mongodb.com/developer/how-to/FARM-Stack-FastAPI-React-MongoDB/), with authentication (https://www.mongodb.com/developer/how-to/FARM-Stack-Authentication/).
Authentication works as it should on Fast API docs and Postman. When executing a successful user log in, it automatically sets the JWT HttpOnly cookie on the browser. When logged in, it removes the cookie again on logout.
When calling /login on front-end, it said following error in the Network tab:
As the error states, I managed to fix this by setting the cookie options on the backend as following, and I could afterwards successfully login from a react front-end:
Unfortunately, this doesn't work for the /logout call. This error occurs again, as the SET-COOKIE header tries to set an empty cookie, yet it can't due to the cookie having a SAMESITE="lax" as default, but I don't see a way to find out how to configure it for the /logout call in the backend.
My front-end /logout call looks like this, the same as /login:
How do I configure my front-end/back-end, so my front-end can successfully delete my cookie and successfully log out?

Keycloak authentication: how can a external user get an token without exposing client secret

I have a query about how keycloak is supposed to be working with client without GUI access.
Basically I have:
A keycloak server configured with a realm, clients(Access type confidential) and Users
A server application with a GUI that also provide API, secure with keycloak (client, user, blablabla)
This is kind of working already as I am able to log on the GUI, have the redirect, etc..
Even accessing the APIs works well, when I have access to a GUI: I log on my UI, follow the redirect and get my UI to display the token. The the human (to differentiate the user from an application), can use the token in any API client.
In this context the user never sees the client secret, which is instinctively the right way. (note that I am very opened to people telling me my instinct is wrong!)
What I am NOT able to do so far is to find the way a server application (without GUI) can get a valid token?
The authorization_endpoint, as far as I understand it, requires both the client id and the client secret) to get a token, which I would rather avoid: I don't think giving my client secret to all my "customers" is the proper way to do it.
Alternatively I could create an API on my client that woudl ask for user credential and ask for the token in its behalf, but that would expose the clients credentials to my application, which is against the whole concept!
I tried setting my client Access type as public, but when I use the API call below I also get a error:
POST /auth/realms/realmname/protocol/openid-connect/tokenAPI
'grant_type=client_credentials'
'client_id=client_id'
'username=username'
'password=password'
{
"error": "unauthorized_client",
"error_description": "Public client not allowed to retrieve service account"
}
Would anyone know how this is supposed to be done ?
Thanks in advance.
Max
(...) A server application (without GUI) can get a valid token... typically using the Client Credentials flow.
But we would define in this case a dedicated Client for your server (client?) application to authenticate against. The returned token (not bound to a specific user) will serve for authorizations on allowed applications (i.e. your classic GUI or API clients).
So, basically you should (in very short):
define a specific confidential Client in your Keycloak
add the desired applications (or other Clients) to the Client Scope(s). Those you want to authorize transitively from this Client.
authenticate against this Client with Client Credentials flow (given the token endpoint, client id, credentials, scope)
ensure that you are authenticating through TLS and that parameters are included in request body (and not in headers - for enhanced privacy)
further harden security of your Client(s)
When you do not want anymore this particular server (client?) application to access your applications, you can change the corresponding "authentication" Client's secret/credentials or simply delete it.
"I don't think giving my client secret to all my "customers" is the proper way to do it."
You are right and the proposed method above strictly avoids that. Each customer would have its own credentials.
EDIT
(adding more details)
By performing as above, you would end up with the following scheme:
Flow Keycloak Server
C/S app. or Customer X <--- Client Creds ---> Auth. Client X
--- Access Token ---> Appl. Client <--> Appl. Server
C/S app. or Customer Y <--- Client Creds ---> Auth. Client Y
--- Access Token ---> Appl. Client <--> Appl. Server
Browser users <--- Standard ------> Appl. Client <--> Appl. Server
Note: this is not a detailed flow chart. Arrows mostly show relationships here.
Finally, please note that the terminology may differ a little here, but the proposed method is basically the same that Google uses. So you may aswell take some inpiration from there:
https://developers.google.com/identity/protocols/oauth2
I just had the same problem some weeks ago
In my case, I have a backend API and a frontend application that the users can use.
Eventually, I can't share the client_secret to the frontend application.
So here is my solution:
On keycloak, create a client (ex front_end_client) with grant type public
This client is going to be used by the frontend application to authenticate users using implicit flow (with PKCE will be more secure)
On keycloak, create a second client (On the same REALM as the first client) with grant type confidential, this client is going to be used by the backend API
Now, this is how it works:
Frontend app authenticate users and get the access token (Using the font_end_client)
The frontend app sends this token for every request to the backend
Backend app verify this token, and can retrieve permissions from it

Keycloak token validation flow

When a request with the bearer token hits a microservice, does microservice talk to keycloak to validate the token for each request?
Is traffic "Step 5" configurable via keycloak adapter?
No, that would make too many requests. In initialization phase microservice loads public key and signing algorithm from Keycloak’s well known config page. On each request microservice checks the signature of the bearer token.
Access token lifespan should not be too long and that is how you force your frontend to periodically go to Keycloak and refresh the bearer.
If you run your microservice, every time you send a request to an api after adding the token in the logs you will see "Loaded URLs from http://localhost:8080/auth/realms/{realm-name}/.well-known/openid-configuration". Upon clicking this link you will see that there are a set of URLs present here, endpoints for token generation, userinfo etc.,there are endpoints for getting the certs and signing keys as well via which the signing key of the token is verified.
(This will only happen if keycloak properties are defined in application.properties/application.yml)
Step 5 will happen on using Keycloak adapter (Choice of adapter given in keycloak documentation)

Accessing REST service after login within browser using oauth2 and spring security using java config

I have implemented Oauth2 using sparkl2 app. I am using spring-security as described in the sparkl2 app using java config. I can successfully get auth token using curl and i can invoke web service using curl.
My question is
How I can access my REST service within the same browser after login into my application? I am not sure what I am missing here?
Let me elaborate my question in more details. The way browser keep session after login and we can access any protected resource in the application, what is the best way to implement so that I can test my REST api from browser
spring security keeps it in session. Session id is stored in browser cookie, so its passed with each request to your service. Then spring security should take it and check if specific session(with user logged in) is allowed to hit this particular url.
I would start with configuring secure paths in your java config:
http.authorizeRequests().antMatchers().hasAnyRole(...)
or some other method instead antMatchers.
you probably have to log in user into spring security on some oauth callback, something like:
Authentication auth = new UsernamePasswordAuthenticationToken(user, null, authorities);
SecurityContextHolder.getContext().setAuthentication(auth);

JMeter test with CAS not redirect to service

I am doing a jmeter test with CAS , but encountered a problem.
I got it logged in succesfully with full of CAS parameters(username/password/lt/service/_eventId), but the response data was not my page specified in the parameter "service".
It is not redirected.
Why? Does anyone know this issue?
I admit that I am not so familiar with CAS...
After reading the protocol of CAS, I find this:
(from http://www.jasig.org/cas/protocol)
2.2.4. response
One of the following responses MUST be provided by /login when it is operating as a credential acceptor.
successful login: redirect the client to the URL specified by the "service" parameter in a manner that will not cause the client's credentials to be forwarded to the service. This redirection MUST result in the client issuing a GET request to the service. The request MUST include a valid service ticket, passed as the HTTP request parameter, "ticket". See Appendix B for more information. If "service" was not specified, CAS MUST display a message notifying the client that it has successfully initiated a single sign-on session.
So ,I add a new request using GET with two parameters:service, ticket(its value is the same with lt).
Then the script run successfully and finally redirected..