Remote authorization on each REST resource request

Question

We have a microservices architecture. One of the components is an Authentication & Authorization Service, which implements OAuth2 standard using encrypted JWTs. On each authentication of a user to any component, the component sends a REST to the service to get an access token. On each REST interaction of a user to any component, the component sends a REST with the user's access token to the service to authorize their right to do the interaction. I have two concerns:

1. Components talk over SSL. OAuth2 requires JWTs to be encrypted, so we blindly follow that and encrypt them. So, encrypted token travels inside the SSL which doesn't make sense to me, but we have a requirement to follow the OAuth2. I feel like OAuth2 means that the JWTs must be encrypted in general, not independently of whether we use encrypted protocol or not (but I am not sure about that).
2. We always ask a remote service for the rights verification, but I feel like a component could just use a public key to verify the JWT's signature and simply read the payload to find the demanded ROLE entry in there without involving the network.

Answer 1

1. To quote RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) here:

In some deployments, including those utilizing load balancers, the TLS connection to the resource server terminates prior to the actual server that provides the resource. This could leave the token unprotected between the front-end server where the TLS connection terminates and the back-end server that provides the resource. In such deployments, sufficient measures MUST be employed to ensure confidentiality of the token between the front-end and back-end servers; encryption of the token is one such possible measure.

2. In theory you can but this means that if someone manages to find an exploit in your token generation, a collision of the signature the JWT has which gives greater rights or something similar they will have more access to the system. By relaying this to a service which isn't editable from the outside you mitigate the risk of this happening. Of course this does mean that you have to protect the rights verification service properly since if that is compromised you're screwed either way.

To continue on point #1, there's some more information within section 5.2 which might be particularly interesting for you considering the first question. I've personally found that most RFCs are very good at declaring the reasoning behind decisions and recommendations so reading them is typically very helpful even though they might seem like dull documents at first.