Token chaining and ID Token / multiple bearer tokens

[Nat Sakimura]

Recently, token chaining use-cases have been popping up. One was discussed at OAuth WG at IETF 114 in Philadelphia and another one as attached in a different forum. (The attachment was provided by Wesley and Brian). This looks like good timing to start discussing. I suggest starting it at the Aug 10 FAPI call. @Brian Campbell if you could chime in this ticket, it would be great.

[Brian Campbell]

I can chime in with a little more context around the attached image/diagram. It comes from an unnamed org’s webpage/document titled “HTTP Header for OIDC ID Token” that also had the following text, “During 2020 [redacted] Summit the chairman of OIDC confirmed that passing 2 bearer tokens is acceptable. [This] proposes to include into […] specification a standardized placeholder for the second bearer token - HTTP request header x-fapi-oidc-idtoken that contains base64 representation of OIDC ID Token issued by OpenID Provider to the client. This will be an optional header that can be included into the API request by an API client.”

There’s been some push-back on all that (rightfully so IMHO) and I think this has found it’s way here in the hopes of getting some broader opinions on whether that push-back is warranted or not.

I also think that the two cases mentioned are different enough from one another that they should probably mostly be discussed independently.

[Nat Sakimura]

So, passing two bearer tokens is obviously OK in some contexts, e.g., OIDC. I am not quite sure, however, what this proposal is trying to do. In the case of the figure, the audience of the ID Token is the client and not the API provider, so the ID Token received at the API provider is invalid.

‌

[Nat Sakimura]

Just found that Kelly’s reply did not reach here (it is on the list) so copying here from https://lists.openid.net/pipermail/openid-specs-fapi/2022-August/002693.html

I presented on token chaining at IETF 114 and would be happy to discuss but am unavailable for this morning's call. I will be available next week and will plan to join the call.

Slides from IETF 114 on cross-domain token chaining are available at https://datatracker.ietf.org/doc/slides-114-oauth-token-and-identity-chaining/

We have not published a draft token chaining document yet, but I am happy to send directly to anyone interested.

Regards,

Kelley

‌

‌

[Wesley Dunnington]

A member of the financial data exchange (FDX) has relayed the following problem.

After a user authenticates with an OpenID provider, the client application has the access and ID tokens. The company would like the client to provide the ID token to the resource server so that the resource server knows the identity of the user. Their proposed solution is to use a header named x-fapi-oidc-idtoken.

The company’s architecture follows zero trust principles. The following is taken from their request to FDX to standardize on the header value:

To implement the least privilege paradigm NIST-800-204 requires the following:

"The token presented to the initial gateway should have permissions with a broad scope whereas the token presented to inside gateways (or microgateways) should be more narrowly scoped with specific permissions or an entirely different token type that is appropriate for the target microservice platform.

This proposal is based on the following assumptions

For operational efficiency a personified "external" access token is “translated” to a de-personified "internal" access token with narrow scope(s). Because of the de-personification such token can be cached by the initial Gateway and re-used to process the API calls from multiple API Clients on behalf of different end users.

Identity of an end user who delegated access to an API Client is still required to be propagated downstream for the purpose of fine-grained access policy decisions and enforcement at the internal API Gateways or within microservice implementations.

To achieve the goal of identity propagation an API provider can require an API client to do the following:

Obtain OIDC ID token from the OpenID Provider along with personified access token.

Supply both tokens in the API requests

OAuth2/OIDC specification only defines a place for a single bearer token - Authorization HTTP Header – allowing to pass one bearer token at a time. There is no standardized placeholder in the HTTP request for the 2nd bearer token, ID token in this case.

There is a diagram attached to this issue that diagrams what they believe the flow would look like. It has been discussed with the requestor that any standard JWT validation would fail since the audience of the ID token is the client application, not the resource server. There is also the fact that the internal services would need to know the JWKS endpoint of both the internal authorization server, as well as the external server that minted the ID token.

Several architectural alternatives are being discussed with the company.

[Joseph Heenan]

For info the minutes from the WG meeting 2 days ago this was discussed at are here: https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2022-08-10_Atlantic.rst#rst-header-id7

I agree with Brian’s comment above that we should separate the discussion of the two different things being discussed, namely:

1. How to do ‘token chaining’ internally within an API provider
2. Protocol changes that would be breaking changes between the RP & AS

I’m not sure there’s a clear expression of the problem “2” is trying to solve, but it appears to me currently to be “how can the perimeter API gateway get identity information”, the one that springs to mind as meeting all the requirements set above being an encrypted JWT access token containing a nested token with that information.

An additional reason not to use the id token is that the claims in the id_token are shared with the client, and for privacy reasons the claims in the id_token shouldn’t be a superset of the claims the client needs and the claims the API provider needs - as that potentially exposes unnecessary PII to both the client and the micro services.

[Dave Tonge]

Discussed on the call and agreed to resolve