Видео

Got it. Thanks

All of these are handled by Spring Data JPA. You can watch this video to understand about the JPA. ruclips.net/video/f5v_4SYS_UE/видео.htmlsi=1nPoUhz-fKTKEMTH

Thank you! I'm glad you found it helpful.

Thank you so much 😀

If possible please share your code via GitHub. You can get my email address from my channel description

Thanks for checking out my tutorial! I didn’t read any specific book to learn Spring Data JPA; I primarily relied on the official documentation, which I found to be incredibly detailed and practical. However, I recently came across a book called Spring Data: Modern Data Access for Enterprise Java by Mark Paluch and Oliver Gierke. It’s written by contributors to the Spring framework, so it might be a great resource if you’re looking to dive even deeper into the topic. Let me know if you have any questions-I’m happy to help!

Thanks for watching. I have a plan to make a video on that. Please keep an eye on my channel.

Hi, I have released a video on this topic. please check it out: ruclips.net/video/RiEqsGbA3RA/видео.html

@LearnWithIfte thanks for making this video

Thank you for your question! The use of .setClaims() when generating tokens depends on how the developer wants to structure and manage the data within the JWT. In some tutorials, .setClaims() is used to set custom claims (key-value pairs) in the JWT payload, which can include user-specific data like roles, permissions, or any other information needed by the application. It allows for more flexibility but also requires careful consideration of the payload size and security. In this tutorial, we may have skipped .setClaims() for simplicity or relied on a different approach, such as setting claims using .claim() or embedding the necessary information directly using other JWT builder methods. If you’d like, I can provide a breakdown or an example showing how to integrate .setClaims() into the token generation process. Let me know!

I'm glad you found the video helpful! I have published videos on refresh tokens. here is the links: ruclips.net/video/nvwKwsJg89E/видео.htmlsi=Fb9mot9tVTLMUROx ruclips.net/video/-DB7zXu8kFU/видео.htmlsi=eupet-HEIXP0XmUx

Thank you for your question! To generate a refresh token for OIDC users, you should include the "offline_access" scope when you request authorization. If you have any more questions, feel free to ask!

I appreciate your feedback! I’ll definitely consider making the steps clearer in future videos. Thanks for pointing that out!

Thank you for your insightful question regarding the implementation of JWT authentication in Spring Security, particularly concerning the use of SecurityContextHolder in a stateless session policy. In a stateless security configuration, the server does not maintain any session information between requests. This means that each request must contain all the necessary information for authentication and authorization, typically provided through a JWT (JSON Web Token). The purpose of the JwtAuthenticationFilter is to validate the incoming JWT and establish the user's authentication context for the duration of that request. Why check if SecurityContextHolder.getContext().getAuthentication() == null? This check is crucial because it ensures that the authentication process is only performed if the user is not already authenticated. If the SecurityContextHolder already contains an authentication object, it indicates that the user has been authenticated in the current request context, and there is no need to re-validate the token. This helps to avoid unnecessary processing and potential performance issues. Why use SecurityContextHolder.getContext().setAuthentication(authToken)? Even in a stateless configuration, it is necessary to set the authentication in the SecurityContextHolder for the duration of the request. This allows Spring Security to recognize the authenticated user and apply any security constraints (like method-level security) during that request. The SecurityContextHolder is designed to hold the security context for the current thread, which is why we set the authentication object after validating the JWT. Once the request is completed, the context is cleared, and no session information is retained for future requests. In summary, while the application is stateless and does not persist session information, the SecurityContextHolder is still used to manage the authentication state for the lifecycle of the current request. This approach allows you to leverage Spring Security's features while adhering to a stateless architecture. If you have further questions or need clarification on any specific part, feel free to ask!

Hey, did you figure this out?

Hello! Yes, you can store both the access token and refresh token in local storage, but it's generally recommended to store tokens securely, such as in HTTP-only cookies, to prevent vulnerabilities like XSS attacks. If you still prefer local storage, just ensure you handle tokens carefully. As for React code integrated with a backend JWT implementation, I don't have a direct reference to share in this comment, but I'll consider creating a video or sharing a repo that covers it in detail. Stay tuned! 😊

Yes, it can be done. In fact, the IDE doesn't matter; you can do it in any of your favorite IDEs.

Refresh tokens are only used to generate new access tokens. You cannot access resources with a refresh token because its sole purpose is to obtain a new access token after the original one expires. Unlike access tokens, which are used to authenticate and authorize requests to protected resources, refresh tokens are meant to securely refresh access tokens without requiring the user to log in again.

@@LearnWithIfte Thank you very much for your response. I added "type" claim to each type of tokens to differentiate it.

The minimum required Java version for this is 17.