Separate signing keys for different services

[PetrS12]

Hello!
In our project there are restrictions on services: in the api information is given depending on the specified service.
In this regard, there was a problem with the separation of "signing_key" for different services, since at the moment you can specify only one single "signing_key" for project.

Thanks!

[radekwlsk]

What do you mean by a service? Could you give an example? Maybe code snippet to reproduce the issue and how you imagine it to be solved.

[PetrS12]

[PetrS12]

There are two cases that cannot be implemented using your library: when the Service A don`t trust the Service B(is presented above(our case)) and when there is one service and several authtorization servers which must have different signing keys(is presented below).

[Andrew-Chen-Wang]

I’m not quite sure how we would implement this... are you asking if we should have a list of signing keys and test against each one until — voila — it works? @PetrS12 I don’t think it’d be an issue to implement, but I’m just wondering how you’d or some other package would do it.

[mjlabe]

What happens if you create a 3rd service? Could this be abstracted out for N services? You could create a mapping of service ID to signing key (great idea btw, I didn't even consider this limitation).

[mjlabe]

Alternatively, I am using this package for an identity service that returns the user's permissions upon login:

 {
   "refresh": "<refreshtoken>",
   "access": "<accesstoken>",
   "user": {
     "id": 1,
     "email": "example@example.com",
     "organization": "Org1",
     "is_active": true,
     "is_staff": true,
     "is_superuser": true,
     "last_login": "2020-03-24T09:33:10-04:00",
     "permissions": [
       {
         "service": "Service1",
         "permissions": [
           "VIEW",
           "ADD"
         ]
       },
       {
         "service": "Service2",
         "permissions": [
           "VIEW"
         ]
       },
       {
         "service": "Service3",
         "permissions": [
           "DELETE"
         ]
       }
     ]
   }
 }

That way the service handles authentication (client - > service - > identity - > service - > client) and then the service knows if the jwt token is valid for their service.

[PetrS12]

What happens if you create a 3rd service? Could this be abstracted out for N services? You could create a mapping of service ID to signing key (great idea btw, I didn't even consider this limitation).

Yes, I can create a dictionary "host": "signing key". And I will add signing key for each host.

Alternatively, I am using this package for an identity service that returns the user's permissions upon login:

That way the service handles authentication (client - > service - > identity - > service - > client) and then the service knows if the jwt token is valid for their service.

I am not sure that it`s good idea for me.

What`s wrong in my solution? #210

[mjlabe]

That's my bad. I was looking on my phone and was thinking this added just 1 extra key. I like the option to specify a key.
+1

[Andrew-Chen-Wang]

@PetrS12 Sorry for taking a looooong time to review your PR. I'm on a bit of a running streak atm of reviewing long lost issues, so bear with me. Unfortunately, I'm also very careful not to allow too many features in SimpleJWT in fear of having too much flexibility which can lead to security vulnerabilities.

So again, bear with me.