Episode 003: 04‐04‐2024 Token Exchange Discussion with Tyk, Gluu, and Curity - GluuFederation/identerati-office-hours GitHub Wiki

Linkedin Event

Description

OAuth 2.0 Token Exchange has been around for a while, and for just as long, token exchange seems to be a dependable source of confusion for API developers and security architects. The goal is to have a deeper conversation about the design Ahmet proposed in the Kubecon talk he gave with Letz Yaara (see video below). "Token Exchange" is probably not officially released in Keycloak because of the questions it raises, especially about inter-domain trust. And if Tyk engineers are struggling with this kind of "simple" OAuth POC, what does it say about the usability of OAuth by API developers at large?

Homework

Kubecon Talk OAuth2 Token Exchange for Microservice API Security - Ahmet Soormally & Letz Yaara, Tyk

Livestream Archive

audio

Takeaways

  • In Ahmet's demo, a website uses Keycloak as the OpenID Provider, which via Keycloak identity brokering to use Google for authentication. The website then uses token exchange to trade its Keycloak access token for a Google access token to call the Calendar API, which is proxied by a Tyk gateway.

  • In order to fully implement RFC 8693 OAuth Token Exchange, the AS would have to perform both federatated trust management (i.e. which issuers to trust) and authorization. And yet, the RFC says "The validity criteria and details of any particular token are beyond the scope of this document and are specific to the respective type of token and its content.". So it's like "Step 1: input subject token... Step 3: issue correct token"--but what happens in Step 2? That's out-of-scope.

  • Jacob pointed out in the post-stream conversation that API developers have three choices: (1) pass token; (2) exchange token; (3) embed token (for example, what if the original token response had three differently scoped access tokens).

  • Token exchange is not the only way to exchange tokens. It's a standard way to do so. And yet, the three vendors we talked about on the call implemented token exchange differently. Which begs the question if a standard way is useful? And this should remind us that OAuth RFC's are the building blocks of technical solutions, need to be profiled, and in some case, the exact use cases have to be communicated with the api developers and the backend domains that issue trusted tokens.

  • For zero trust, it would be better to use reference tokens everywhere--even on the "internal network" (which is just as untrusted...). But this is incompatible with microservices which preclude any network or persistence dependencies. So JWTs are preferred, because they contain all the data and security (signatures).

  • The subjects web session is changing, for example a person my FIDO authenticate, proving their presence. How are these real-time changes propagated through the tokens? Is token exchange really the best way to get updated security information? Perhaps we need more adoption of pub-sub asynchronous protocols like CAEP, which details how to communicate changes.

  • RFC 8693 Token Exchange Sequence Diagram Sample