#Designing a secure microservice system

1 messages · Page 1 of 1 (latest)

flat fable
#

I've been working on a webapp using Spring Boot that uses microservices.

It contains:

  • A Spring Cloud Gateway service to access other internal microservices
  • Authorization service for managing security stuff using JWT tokens
  • Other various internal services

The way I've set up my security thingie is that, in the Spring Gateway, I've made a filter that reads the bearer token from the request and verifies it using the authorization microservice. If the token is valid, the request passes further, otherwise it throws 401. The route builder is then configured to have the filter applied to specific endpoints in the gateway. The actual endpoints on the internal services, for the exception of auth service, remain unsecured.

I plan on (eventually) deploying said app using Kubernetes and while, as far as I'm aware, there shouldn't be any issues with this setup if I configure the cluster correctly (API authentication, RBAC, etc.), I'd like to double check if this is true or not.

And, in the case it isn't, what's the better method for securing microservices?

copper moonBOT
#

<@&987246841693360200> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
I've been working on a webapp using Spring Boot that uses microservices. It contains: - A Spring Cloud Gateway service to access other internal microservices - Authorization service for managing security stuff using JWT tokens - Other various internal se

When designing a secure microservice system with Spring Boot, it's important to consider implementing proper security measures such as authentication, authorization, and encryption.

Here are some key considerations:

  • Implement OAuth2 for authentication and authorization
  • Use HTTPS to secure communication between microservices
  • Implement role-based access control to restrict access to sensitive data

Useful links:

- AI generated response
copper moonBOT
#

@flat fable

Your question has been closed due to inactivity.

If it was not resolved yet, feel free to just post a message below
to reopen it, or create a new thread.

Note that usually the reason for nobody calling back is that your
question may have been not well asked and hence no one felt confident
enough answering.

When you reopen the thread, try to use your time to improve the quality
of the question by elaborating, providing details, context, all relevant code
snippets, any errors you are getting, concrete examples and perhaps also some
screenshots. Share your attempt, explain the expected results and compare
them to the current results.

Also try to make the information easily accessible by sharing code
or assignment descriptions directly on Discord, not behind a link or
PDF-file; provide some guidance for long code snippets and ensure
the code is well formatted and has syntax highlighting. Kindly read through
https://stackoverflow.com/help/how-to-ask for more.

With enough info, someone knows the answer for sure 👍

flat fable
#

Nuh uh

paper sonnet
#

It look good, did you make sure to use a jwt lib that has no failures?

#

Also, did you setup a time limit in the token itself?

#

Did you encrypt the payload before even building it.

#

Has your token no public info that can be inspected to determine your user type, or role.

#

Add 2 time stamp on the token, the creation, and its end.

#

Do you have an endpoint that can renew still valid token?

#

You should not be able to reuse a token multiple time later

flat fable
# paper sonnet You should not be able to reuse a token multiple time later

In order:

  1. I use JJWT, which at the very least seems fairly common
  2. Yes
  3. It's only signed. Gonna fix it now
  4. The subject field in the payload has the user's ID, which is technically public. I guess adding another internal unique authentication ID could help that though
  5. Expiration date and issued at fields are already there
  6. Unfortunately I didn't know you shouldn't be able to reuse tokens, so the system is currently set up in such a way that you basically hold on the token up until it is expired but I'll fix that

Thank you!