1. The Mobile or Web application requests an Access Token from Curity.
  2. Curity responds with the Access Token.
  3. The application requests access to the remote resource (i.e API A)
  4. The API Proxy intercepts the request and extracts the Access Token from the Authorization Header. It checks its cache to identify if this Access Token is already found active previously.
  5. In case the Access Token was not verified earlier, it sends a request to the introspection endpoint.
  6. Curity replies to this request according to RFC 7662. The body of the response contains a JSON with a boolean active property.
    1. When the Access Token is not active, the API Proxy replies to the application with status code 401 Unauthorized
    2. When the Access Token is active the API Proxy forwards the request to the API, after it replaces the Access Token with the JWT which was in the body of the introspection endpoint’s reply (6).
  7. The API, after validating the JWT token, using the Curity’s public key, has access to information about the user, handles the request and responds accordingly.
  8. The API proxy forwards the API’s response back to the application.


This is a simple flow, where some error cases are not presented. For example if the original request (3) does not have an Authorization Header, the proxy has to reply with 401 Unauthorized. Moreover, the API must respond accordingly when receiving an invalid or expired JWT.