The OAuth/SAML flows do not preserve caller context, so federated users cannot complete the repo’s advertised multi-service/browser flow. The docs promise audience-scoped downstream tokens and BFF/browser-style integrations (README.md), (README.md), (service-api.md), (service-api.md) but OAuth only stores redirect_uri, then issues a default token pair with no audience argument and returns JSON from the callback instead of redirecting back to the caller (oauth_service.py), (oauth_service.py), (token_service.py), (oauth.py). SAML has the same problem and additionally ignores the incoming relay_state by replacing it with an internal token (saml_service.py), (saml_service.py), (saml.py), (saml.py). In practice, Google/SAML logins can only mint auth-service tokens, not orders-api/billing-api tokens, and the stored redirect/relay context is dead code.
The OAuth/SAML flows do not preserve caller context, so federated users cannot complete the repo’s advertised multi-service/browser flow. The docs promise audience-scoped downstream tokens and BFF/browser-style integrations
(README.md),(README.md),(service-api.md),(service-api.md)but OAuth only storesredirect_uri, then issues a default token pair with noaudienceargument and returns JSON from the callback instead of redirecting back to the caller(oauth_service.py),(oauth_service.py),(token_service.py),(oauth.py). SAML has the same problem and additionally ignores the incomingrelay_stateby replacing it with an internal token(saml_service.py),(saml_service.py),(saml.py),(saml.py). In practice, Google/SAML logins can only mintauth-servicetokens, notorders-api/billing-apitokens, and the stored redirect/relay context is dead code.