0

I've multiple clients which they have an API, my micro service send them a post request with a JWT token. I was thinking of using IdentityServer4 to generate my JWT token (RSA256) and have one configuration per client. Each client, can validate the token thanks to JWKS_URI.

It is a good approach to do this ?

enter image description here

EDIT Update Diagram : I separed layers, separating the sender from the receivers.

enter image description here

EDIT Update Diagram : I update my diagram who would be more explicit :

enter image description here

Thanks for yours comments

Julien Martin
  • 197
  • 2
  • 15

1 Answers1

1

In IdentityServer terms the MicroService is a client and client1/2 is an ApiResource (tied to an ApiScope).

If there is no user involved and the Microservice should on its own be able to send requests to the API, then you should use the client_credentials flow. With with flow, there is no ID-token.

If there is a user who is logs in at your microservice, then you should use the authorization code flow.

Otherwise than that I think its a good plan, you should think about the naming of things. I would call the Microservice a WebClient or WebApplication if there are users who logs in through it.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • Yes no user involved and microservice itself send requests to API. Yes I use client_credentials. The microservice is a .net core app host as Windows Service. – Julien Martin Dec 17 '21 at 13:45
  • Yes, that sounds like a good idea! – Tore Nestenius Dec 17 '21 at 15:24
  • There is a question on all my mind, normaly, isn't ApiResource (client1 and client2) which validate token and receive claims ? But as I've a special case, it's my microservice to do this. – Julien Martin Dec 20 '21 at 08:19
  • Yes, The client1+2 in your diagram are the API and should preferable be mapped as ApiResources in IdentiyServer, see my answer here for more details – Tore Nestenius Dec 20 '21 at 10:00
  • Have you got forget a link for more details ? – Julien Martin Dec 20 '21 at 10:08
  • yes, sorry, here it is https://stackoverflow.com/questions/63811157/apiresource-vs-apiscope-vs-identityresource/63812939#63812939 – Tore Nestenius Dec 20 '21 at 10:11
  • Your diagram help me to understand the concept, but client1 and client2 are business client, I can have 1000 clients for example, so they can't be mapped as ApiResources and validate token and receive claims. So my microservice is both Client and ApiResources... – Julien Martin Dec 20 '21 at 10:42
  • I guess you need to treat some services both as clients and and scopes, as OpenID-Connect is more for "one-way" communication than bi-directional. Also it gives a layer of security by separating the sender from the receivers., but it all depends as usual. – Tore Nestenius Dec 20 '21 at 10:49
  • I updated my diagram to separate layers – Julien Martin Dec 20 '21 at 12:27
  • I don't think ApiResource should be a separate thing in your diagrams, its the receivers of the API tokens... but Should you really "post" to the clients, perhaps better if the clients only poll for information? Seems a bit over-complex to have 100's clients to post to. – Tore Nestenius Dec 20 '21 at 12:33
  • In fact, microservice is triggered by my RabbitMQ's messages, microservice is like webhook, it processes messages and send them (post request with JWT token) to multiple clients. – Julien Martin Dec 20 '21 at 13:13
  • However, including tokens in the queue seems like a bid idea, as tokens have a fairly short lifetime, like 1-60 minutes and then if the clients are down for like +1 hour, then all messages would fail authentication. – Tore Nestenius Dec 20 '21 at 13:49
  • sorry I expressed myself poorly. Tokens not are in queues. when a message is in queue, microservice is triggered and process message, generate jwt token and send to client. – Julien Martin Dec 20 '21 at 14:43
  • aha, ok., i got it! – Tore Nestenius Dec 20 '21 at 15:12
  • So you think my diagram is logic ? – Julien Martin Dec 20 '21 at 15:19
  • It is hard to tell, as I don't have the full picture, I think diagrams are useful, but perhaps more important are the data-flows, and not the background requests like getting keys to validate tokens (Those are not the important ones.). Also I think its more clear if the diagram was more obvious about what is the client and what is the API. – Tore Nestenius Dec 20 '21 at 16:46
  • I updated my diagram, it may be more explicit. – Julien Martin Jan 04 '22 at 09:02