0

As a learning exercise I want to develop a system using microservices. I have designed my authentication/authorization architecture and would like to know if there are drawbacks to my design. It is as follows:

  • Authentication service has following tasks:

    • Issue JWT signed with RSA key that does not expire
  • Gateway that has following tasks

    • route unauthenticated requests to authorization service
    • route authenticated services to resource services
    • issues session tokens to end users that are stored in distributed key-value datastore (e.g. Redis) and maps them to JWT issued by auth service
  • Resource services that validate JWT signature using static public key

Are there any drawbacks? What could I improve, change?

  • 1
    Can downvoter elaborate -1? Maybe I actually can improve my question. – Heisenberg Feb 29 at 12:43
  • Are you saying that your authentication server is a resource (in the REST sense) on the gateway? – K Mo Feb 29 at 14:57
  • @KMo That is correct, it is a REST service – Heisenberg Mar 1 at 13:32
0

Seeing the words...

key that does not expire

sends a cold shiver down my spine.

I get that this is just a learning excersize and may not have real consumers and/or data, but that's just bad practice and suggests that there is something missing from your architecture.

Maybe it's just the wording you have used, but...

route unauthenticated requests to authorization service

No. Gateway should route requests for tokens to the authentication service and reject/provide redirect for other resource requests without tokens.

route authenticated services to resource services

issues session tokens to end users that are stored in distributed key-value datastore (e.g. Redis) and maps them to JWT issued by auth service

Resource services that validate JWT signature using static public key

All of this a bit trickier to unpick. It seems to suggest that you are authorizing in the gateway and resource servers. Although I suspect the gateway is blindly acting on anything in an authorization header.

There is no point in your gateway creating sessions for unauthorized requests (well OK, maybe there is, but it should know if the user is authorized at this point).

An issue with doing the authorizing on the resource servers is that you'd have to scale both the gateway and resource server in case of an influx of requests with malformed or expired tokens.

It also means any changes to your auth flow will be affect all resource servers.

| improve this answer | |
  • What would be a way of maintaining expiry/refresh tokens? It seems burdensome to request to request new token from auth service for all requests. The alternative to it is OAuth2 and refresh tokens. Is there any other alternative? – Heisenberg Mar 1 at 21:30
  • Any auth token should be time limited, its up to you whether you force the user to login again after the token expires or manage refresh tokens for the frontend to manage. It really depends on usage habits and/or the security impact of having a long running token. – K Mo Mar 1 at 21:52
  • Yes, but in my scenario auth tokens never leave infrastructure thus making them less vulnerable to hijacking. But yes, I see the problem, so probably I will go with reissuing token upon each request with new expiry time. – Heisenberg Mar 1 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.