A diagram of the event architecture for an event.

Scaling Token Revocation with Continuous Access Evaluation

Executive Summary

In today’s app economy, more and more client interactions and transactions are occurring via the web and mobile applications, where predominantly APIs are being used for Information Exchange. This enables modern enterprises to break the traditional barriers and expose their on-premises and cloud-based digital assets and applications to the outside world in a secure manner.

Correspondingly, whether it is a traditional Web, modern SPA, or native Mobile applications, both OAuth2 and OpenID Connect (OIDC) security protocols has become an industry standard in providing the required API security. Especially noted is that OIDC with JSON Web Token (JWT) is becoming the gold standard for the enterprise due to its benefits (self-contained, session-less, good performance, Decoupled/Decentralized generation and validation). Many organizations are leveraging JWT in their environment not only for user identification but also for more granular (fine-grained) authorization. One of the benefits of JWTs, as compared to opaque access tokens, is that relying parties can validate those tokens locally without having to check back with the trusted token issuer (OAuth provider). Unfortunately, the ability to revoke tokens after issuing is considered a tradeoff of JWTs because relying parties need to check back with the token issuer to know whether a token has been revoked.

In this blog, we shall examine the use of Continuous Access Evaluation (CAE) and Signal Sharing Event (SSE) framework to enable relying parties to support token revocation without the need to constantly contact token issuers at runtime.

Continues Access Evaluation (CAE)

With this context being set, I want to pivot and focus on the “Continues Access Evaluation†model, where issued access and refresh tokens are being leveraged for both authenticating and authorizing the request. And if access token expires, then refresh token is being leveraged to receive new access token without any friction, and this is a standard mechanism. But what if the issued access token is valid (not yet expired) but it has been revoked due to:

  1. User termination
  2. Password reset/changed
  3. User location changed
  4. User device was compromised

Without knowing the occurrence of these events and revocation conditions of issued access token, many downstream applications or microservices may continue to validate and authorize the received JWT access token (like signature, expiration and audience claims, etc.,) locally.

Above scenarios can easily become a serious security breach, and situations like this are being solved using CAE, by sharing these events to downstream applications or microservices. When such an event occurs, the provider can revoke the issued access token and publish the events with relevant information, which can be received by subscribed application and accordingly handle the situation and thereby avoid any potential threats.

As part of this blog, I have a sample implementation that would showcase the CAE and signal sharing event flow, please refer to the component architecture diagram below along with implementation strategy.

Approach using API Gateway with OIDC Provider

Please refer to the sequence diagram below. In this example, we have two parts:

  1. Authentication Request
  2. Routing Request
  1. We have our OIDC provider, which issues and manages the token(s), and the edge gateway acts as the relying party which will delegate the user authentication/authorization request to the provider.
    1. Whenever a provider revokes an issued access token due to any of the above listed events. A shared signal event with relevant information regarding the revoked access token will be published to a JMS, Kafka, RabbitMQ, or any other message broker systems.
    2. All subscribers to that event will receive the signal regarding the revoked token and this information will/can be cached (Hazelcast or Redis) for later reference.
  2. When a Gateway receives a routing request with authorization header (Bearer JWT), it will route incoming requests to downstream applications/microservices after validating/verifying incoming access token.
    1. As part of validation:
      1. Gateway will verify whether the incoming access token has been revoked or not by a simple cache lookup. If the token exists in cache, then it will reject the request with a relevant revocation error message.
      2. If incoming token is not found in the revoked list (cache), it will further validate the token signature, expiry and audience and accordingly authorize the request.
      3. If the incoming token has expired or not having required authorization, it will reject the request with a relevant error message.

Conclusion

As discussed earlier, CAE is two parts, where the OIDC provider manages the issued token based on events and (1) publishes them to a centralized message broker, which can be (2) subscribed by other downstream applications/web services and manage the incoming tokens accordingly. In an edge API gateway environment (above example), this can be centrally managed via the gateway, which could subscribe for the specific events (topic or queue) and handle the incoming routing request accordingly. One of the benefits of JWTs, as compared to opaque access tokens, is that relying parties can validate those tokens locally without having to check back with the trusted token issuer (OAuth provider). Unfortunately, the ability to revoke tokens after issuing is considered a tradeoff of JWTs because relying parties need to check back with the token issuer to know whether a token has been revoked.

The Layer7 API Gateway’s OOTB capability to subscribe to a token revocation evens via a message broker can be easily configured in your API policies.

If you don’t have Layer7 API Gateway then, you need to ensure your gateway provider provides similar support to a wide range of security protocols and solutions that would suffice your CAE requirements. Similarly, if you don’t have VIP Authentication Hub, then please make sure your OIDC provider has the most modern, secure omni-channel user authentication solution that would enable password less for your application and also risk based multi-factor user authentication solution that includes biometric, Security key, PUSH and Mobile OTP factors.