Learn how to build a secure CRUD app with Spring Boot and Angular. You’ll use Auth0 for authentication and authorization and Cypress to verify it all works.
Read more…
Brought to you by @mraible
What’s up Devs! How did you like this post? Please share any comments or feedback with us on this thread
Hey ! Thanks for this informative blog.
I had one query on the security part of things.
I see that Angular calls api/user to initiate the OAuth flow and gets the required user details. But where is the JWT token that needs to be passed as a Bearer token to all the other group apis.
Thanks
The OAuth flow happens on the server side. The login button goes to a Spring Security endpoint (oauth2/authorization/okta). From there, Spring Security handles redirecting to Auth0, handling the callback, and talking to the token endpoint to get the access token + ID token. There is no access token passed to the Angular client.
This is the most secure way to integrate Spring Boot and Angular. It won’t work if you want to host your Angular and Spring Boot apps on different domains.
You can check out my Angular Mini-Book if you want to do the authentication in Angular and treat Spring Boot as a resource server. Chapter 2 has all the details for that type of architecture. FWIW, an update of the book is currently in progress.
1 Like
Thanks for the details.
So if I understand it correctly, Spring boot gets the access token + ID token, populates the Principal and then continues to work with the current session of the browser with the help of cookies just like a regular web application.
Is that right ? 
Yes, that is correct.
2 Likes
Thank you for the comprehensive guide. I have a query regarding the interaction of Angular with microservices in an OAuth context. If I understand correctly, with the current setup, the Angular app is only able to directly interact with the service handling OAuth login. But how should I set it up in a microservice architecture. Could you please validate my understanding of the following alternative approaches?
API Gateway Approach: In this setup, the API Gateway would handle authentication and route client requests to the appropriate microservice. Specifically, the Gateway communicates with the User Service to manage the authentication process and secure an access token. The Gateway would then include this token when routing requests to other microservices on behalf of the Angular client.
Shared Authorization Service Approach: In this approach, each microservice would independently validate the access token. An overarching Authorization Service would be responsible for interfacing with Auth0 to authenticate, secure the access token, and store it within a server-side session. The session ID would then be stored as a cookie in the client’s browser. Consequently, when the Angular app initiates a request to any microservice, it would include this session ID cookie. Each microservice would then use this session ID to retrieve the corresponding access token for validation.
@JangoCG Your understanding of the two approaches is correct. Let me validate and provide some additional information:
API Gateway Approach:
In this approach, the API Gateway acts as a single entry point for client requests and handles authentication and routing. The Gateway communicates with the IdP like Auth0 to authenticate the user and obtains an access token. This access token is then included in the headers of subsequent requests to other microservices on behalf of the Angular client. This is the setup used in JHipster microservices, for example.
This approach centralizes the authentication logic in the API Gateway, making it responsible for handling authentication and authorization for all microservices. It simplifies the client-side code as the Angular app only needs to obtain and include the access token in the initial request to the Gateway.
Shared Authorization Service Approach:
In this approach, each microservice independently validates the access token. An Authorization Service, which interfaces with an IdP like Auth0, is responsible for authenticating the user, securing the access token, and storing it within a server-side session. The session ID is then stored as a cookie in the client’s browser. An example of this would be using something like the OAuth2-proxy application, which is quite useful in service mesh-like use cases.
When the Angular app makes a request to any microservice, it includes the session ID cookie. Each microservice then uses this session ID to retrieve the corresponding access token from the Authorization Service for validation.
This approach allows each microservice to have its own authentication logic and validate the access token independently. It provides a level of decentralization, allowing microservices to be developed and deployed independently. But on the downside, you now have a lot of repetition and overhead.
It’s worth noting that both approaches have their pros and cons, and the choice depends on your specific requirements, architecture, and team capabilities. The API Gateway approach is more centralized and can simplify client-side code, while the Shared Authorization Service approach provides more flexibility and decentralization.
2 Likes