The question of how much control to retain versus how much to give up is something that occupies the minds of parents, management consultants, and often coaches. A high level of control helps achieve specific objectives, but, at the same time, it may lead to a complex bureaucracy that slows down self-initiative, entrepreneurship, and general productivity. A high level of empowerment, on the other hand, fosters creativity and ownership, but it may lead to unmanageable or risky outcomes.
In the world of identity and security, organizations across all sectors also face this conundrum. Managing identity involves both controlled (stateful) and autonomous (stateless) security tokens.
- Stateful tokens are opaque and can be de-referenced by a central authority only after request (token introspection). The authority manages the state of the token, including revocation. The token depends on the availability and performance of the authority.
- Stateless tokens are self-contained and can be “unpacked” by any party with the appropriate key material. Stateless tokens can be processed with or without the availability of an authoritative service.
Knowing which to use is often straightforward, but sometimes what you really want to deploy is something in between.
A Closer Look at Token Swapping Use Cases
Exposing open services and APIs to external clients is a perfect use case for stateful tokens. Because external clients can be located anywhere and security tokens can travel over many networks, more control is needed. With stateful tokens, you can have opaque tokens that don’t carry sensitive content, always introspect tokens against a central authority, and revoke tokens as needed to provide a high level of control.
However, for Zero Trust architectures that require security checks at every stage, including each microservice-to-microservice call, using stateless tokens makes more sense. That’s because they don’t depend on a central authority, which could impact the ability to scale and to continue operations if the authority is unreachable.
Token swapping describes the ability to exchange one security token for another in a different, enriched, or restricted form. A gateway can function as the “token swapper.” It intercepts requests, validates tokens, and generates new tokens either by itself or in conjunction with other services.
Let’s look at the example of a financial company exposing APIs to partner organizations. Such a scenario requires a higher level of control and the ability to revoke granted access, so, for these external clients, the financial institution issues stateful tokens. Token swapping allows the company to use those stateful tokens on the front end but then switch to stateless tokens for scalability and other benefits within their microservices environment.
If you swap a stateful token for a stateless token in the right way and at the right time, you can achieve that delicate balance between control and autonomy to better suit your purposes.
In the aforementioned scenario, ForgeRock Identity Gateway, deployed as a north-south gateway, validates stateful OAuth2 tokens by introspection with ForgeRock Access Management, ForgeRock Identity Cloud, or any other OAuth2 authorization server. After validating the stateful token, Identity Gateway then generates a stateless JSON Web Token (JWT) containing the identity information the downstream services need to proceed autonomously.
Self-contained JWTs are a compelling token type for scenarios that require a high level of scaling, do not have a strong dependency on external services (such as the authority), and can tolerate the absence of token revocation capability. For many microservices scenarios, this is a very effective use case for token swapping.
Local JWT validation can also be conducted by service meshes, such as Istio, or by ForgeRock Identity Gateway, deployed as an east-west gateway, or Microgateway with the JwtValidationFilter. Note, however, that service meshes support self-contained JWTs but do not integrate well with stateful OAuth2 and remote token introspection. Furthermore, JWTs consumed by service meshes like Istio need to have the appropriate content, which can be built using token swapping. The “token swapper” can aggregate the appropriate JWTs.
Token swapping is not limited to stateful OAuth2 to JWT token swapping. You can create transformations using other token types – such as OpenID Connect, SAML or SSO tokens – and services like the security token service (STS). You can also enrich tokens with user roles, entitlements, or attributes obtained from the authority.
To learn more about balancing control and autonomy with token swapping, read about the following useful components: JwtBuilderFilter, JwtValidationFilter, IdTokenValidationFilter, OAuth2ResourceServerFilter, TokenTransformationFilter.
With token swapping, you can expand your options for obtaining the right balance in the control versus autonomy dilemma—at least in the identity and security realm. Parents, philosophers, and management will have to look elsewhere.
The post Balancing Autonomy and Control in API Security with Token Swapping appeared first on Security Boulevard.
The post Balancing Autonomy and Control in API Security with Token Swapping appeared first on Malware Devil.
https://malwaredevil.com/2020/11/05/balancing-autonomy-and-control-in-api-security-with-token-swapping/?utm_source=rss&utm_medium=rss&utm_campaign=balancing-autonomy-and-control-in-api-security-with-token-swapping
