I have Spring Boot API and a React.js/Redux Frontend.
I want to secure all POST routes plus some GET routes. Only one GET route should be open.
What I did so far is using an access_token (Spring Security). But since there is no login (there are no users for this API) the access_token needs to be static in the Frontend - which is unsecure.
So where can I put the access_token so that the client can access but no one else?
Related
I'm developing a backend server for my applications. Actually, I'm using Keycloak as Identity Provider exploiting the OpenID Connect protocol. The frontend redirects users to Keycloak Login Page, so a token is returned to it. The frontend makes an authentication request to the backend using the returned token. Backend asks the IDP to validate the token and retrieve user info and roles.
Then I want to generate a JWT from the backend in order to easily authenticate the frontend requests.
Is this architecture fine? Or am I missing something important? Can I implement this architecture using Spring Security? Where can I learn more about it?
Thanks for any advice and support.
I have to build an application by using microservice architecture. I divided the whole system into multiple components and each component represents a spring boot project. There are several spring boot projects around 6. I have used the eureka server to register all the services for load balancing. A separate Spring boot project has been developed for the web portal and that application contains authentication, authorization with spring security, and JWT protocol. Now I have 7 projects including a web portal and each project has controller classes under the controller's package.
Now I need to know the following things,
SignUp and SignIn request come to the web portal and after signing a JWT token is generated and it is sent to the client but the Authorization part is only available in the SecurityConfig class on the web portal. So should I send all the requests from the client to a component through the web portal each and every time after authenticated?
Client ----------------> Web Portal ------------------>Service/Component
I need to know that can I send a request to another component/service directly like below?
username + password
Client ---------------------------------------> Web Portal
JWT token
Client <-------------------------------------- Web Portal
JWT token
Client ------------------------------------------> Service/Component
likely yes, because JWT is something available with the user and every time he sends the request, the token shall be validated by the issuer or in cases when we black list some tokens then those requests shall not be processes directly.
In microservices, the API gateways take care of these things and after checking for role and permissions, it forwards the request to the respective microservices based on the incoming route or URI which is then mapped to URI of backend service registered in Eureka server.
I need to secure my spring REST APIs with access token obtain from Keycloak and validation done by Spring security adapter.
I have my mobile client which will be calling APIs from my server which needs to be validated with access token obtained from Keycloak
You can find an example with what you need wright here:
https://github.com/iuliazidaru/keycloak-spring-boot-rest-angular-demo
I am new to spring security
I have a front end application built using vuejs which calls spring rest api to interact with the backend system.
I have a login page where user enters the password. I want to be able to authorise the user if his login is correct and for the subsequent request authorise him with rememberMe token.
I know there is a lot of information available on the topic but
What is the right way to implement?
Should i use basic authentication ? If I am using basic authentication , how should i set up remember me along with basic authentication?
Should the authentication be handled in post call instead of using a auth filter?
Here are two scenario
If your front-end is built on any frontend framework and it's not dependent on any Server Pages(e.g JSP, Freemarker, velocity) or you want your frontend application to connect to your backend application through web services(Rest web service or SOAP web service) then you need to implement your own token base authentication with help of spring security instead of Basic Authentication of Spring security.
Else you should go with Spring Security Basic authentication, for implement Remember-me with spring security, Spring Security provides two implementations for Remember-Me :
1: Simple Hash-Based Token Approach: It uses hashing to preserve the security of cookie-based tokens
2: Persistent Token Approach: It
uses a database or other persistent storage mechanism to store the
generated tokens
Here is spring remember-me doc for it
We have a Java 8 backend application using SprintBoot with an embedded Jetty server.
The UI for the application is a Single Page Application built using React.
Currently I have enabled authentication by integrating with Okta using the spring security SAML extension. When the assertion is posted by Okta to my app, I create a session and the JSESSIONID is sent in the cookie.
This was fine until now when we had a very simple UI serving few UI components.
However, now we have several REST endpoints in our backend and we would want them to be authenticated as well. REST endpoints themselves are developed using Jersey.
If I understand correctly, SAML is clearly not the choice for pure REST based endpoints as SAML is mainly a browser based protocol. These REST endpoints will be called by our UI as well we want them to be independently called via Postman or something for testing.
When a client would call these REST APIs, I am guessing the client should send an Authorization header which should be checked by one of the authentication filters in the backend. After validating the client and the user, the filter should inject the user information in the SecurityContext because Jersey injects SecurityContext in all of the REST endpoints. Then it becomes easier to fetch the user from this SecurityContext.
Upon reading, it seems Okta OpenID Connect can be one choice which issues a JWT. However I am not clear on how to use this. That is, when Okta issues a JWT should our UI or any client for that matter keep sending the JWT in the Authorization header to our APIs and then our APIs in turn should send the JWT to Okta to validate it?
Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints? Not to mention the REST APIs will be stateless in nature.
When a client would call these REST APIs, I am guessing the client
should send an Authorization header which should be checked by one of
the authentication filters in the backend
In OpendID Connect (OIDC), that value in the Authorization header is id_token which can be in JWT format. This id_token is issued by the OIDC server as the last step for whichever OIDC grant type you choose and applicable to your case.
Upon reading, it seems Okta OpenID Connect can be one choice which
issues a JWT. However I am not clear on how to use this. That is, when
Okta issues a JWT should our UI or any client for that matter keep
sending the JWT in the Authorization header to our APIs and then our
APIs in turn should send the JWT to Okta to validate it?
Think that you have 3 components in this architecture. Relying Party (client), Identity Server / Authorization Server / OIDC Provider and Resource Server (your backend and it's data). When Authorization Server issues and id_token to Relying Party, your Resource Server also knows this token. So when you request for data in resource server, you will present your id_token to Resource Server and it knows if it is valid id_token or not
Question is what is the best choice to serve both, a login for the UI
and a session and authenticating REST endpoints?
OIDC Provider (or Identity Server if you need more complex operation), since OIDC is Authorization (OAuth 2.0 at core) and Authentication.