aud to use in client_assertion passed to Backchannel Authentication Endpoint is murky?

[Joseph Heenan]

We came across what looks like an oddity whilst implementing tests; I’m not sure if I’ve missed a specification or if there is something that could benefit from clarification:

I can’t entirely figure out what the ‘aud’ value in a client assertion to the backchannel authentication endpoint should be.

The client assertion spec, https://tools.ietf.org/html/rfc7521#section-5.1, says:

 Audience
      A value that identifies the party or parties intended to process
      the assertion.  The URL of the token endpoint, as defined in
      Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate that
      the authorization server is a valid intended audience of the
      assertion

‌

https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication doesn’t seem to add any clarity.

By contrast, the CIBA request object is quite clear: “The Audience claim MUST contain the value of the Issuer Identifier for the OP, which identifies the Authorization Server as an intended audience.”

The three possibilities for the audience for client assertion seem to be:

1. the token endpoint (as RFC7521 says)
2. the backchannel authentication endpoint (because that’s where the assertion is being sent)
3. the issuer (to match the CIBA request object)

The server I’m trying against (Authlete) seems to have interpreted it as ‘2’.

[Brian Campbell]

I’m afraid this situation is partially, if not largely, my fault. But also an artifact of the timing of when some of these specs came to be and doing the best with what was available at the time.

RFCs 7521 & 7523 were developed before there was a single identifier value available to indicate the authorization server (now there's the issuer from RFC 8414 but that didn't exist at the time). So they kinda recommended the token endpoint URL as an audience value to identify the authorization server (the token endpoint was the only endpoint that did client auth when they were started). But also left it open saying that aud could have basically any "value that identifies the authorization server as an intended audience" and that the "authorization server MUST reject any JWT that does not contain its own identity as the intended audience". It was the best I could come up with at the time given what was available. It makes sense at some level and is consistent with the base definition of aud from RFC 7519. But it’s not ideal with respect to interoperability.

OIDC core did have an Issuer value that in hindsight probably could/should have been required or recommended for the audience value for client assertion auth. But it pretty much just followed RFCs 7521 & 7523 saying “The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.”

It does get a bit murky and ugly when the client assertion is presented at a different endpoint, however. CIBA’s backchannel authentication endpoint is one such endpoint but not the only one - there is also revocation, introspection, and maybe others I’m not thinking of at the moment.

As I read the specs involved, I think it comes down to the AS needing to verify itself as an intended audience. And that could/should/may be via the token endpoint URL. But *could* be another value too. Like the OIDC or RFC 8414 issuer value. Or the backchannel authentication endpoint.

From an interoperability perspective, I think that an AS should be prepared to accept any one of the 1., 2., and 3. you list.

I’m honestly not sure what’s best for a client to do with client assertions to the backchannel authentication endpoint. The most literal reading of the specs would suggest the aud value should be the token endpoint URL. Which is legit but admittedly a little awkard. To me, the OIDC or RFC 8414 issuer value makes the most sense but that has to be inferred. Similarly the backchannel authentication endpoint URL makes a certain amount of logical sense but that also has to be inferred. We could perhaps pick one and suggest it in the CIBA spec? But I do think that for interoperability AS's should accept all three. Maybe that should be suggested in the CIBA spec as well?

[Filip Skokan]

My AS implementation also uses 2. - token endpoint URL when the assertion is used at the token endpoint, introspection endpoint URL when used at the introspection endpoint and so on.

At the same time my client implementation also sticks to this scheme.

I agree with Brian the AS should accept at the very least the issuer value or the endpoint url and to 100% adhere to the specs, also the token endpoint (sad).

[Joseph Heenan]

Thanks Brian, that’s very comprehensive. Thanks Filip too!

I think I agree with Brian’s logic.

I think given the lack of other clarity, including something in the CIBA spec makes sense. I think this would be:

1. AS should (must?) accept all 3 values
2. RP should (must?) send one particular yet to be determined value

[Joseph Heenan]

Another data point (thanks to Filip for pointing this out):

PyOIDC sets the aud to the token endpoint for the token endpoint (and the “refresh” endpoint whatever that is?), and otherwise sets the audience to the issuer.

https://github.com/OpenIDC/pyoidc/blob/master/src/oic/utils/authn/client.py#L310

(frustratingly I can’t find any discussion of why this was believed to be correct; there’s nothing in https://github.com/OpenIDC/pyoidc/pull/430 where this change was added)

[Filip Skokan]

I can’t find the issue in https://github.com/openid-certification/oidctest (where i’m sure it is somewhere) either.

The reason behind using issuer when not calling the token_endpoint i can’t say for sure but if i’m to assume it was to minimize the impact of the change and only isolate it to what the certification test needs to test, which is

The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

There are no tests expection assertions on other endpoints (there’s no introspection, no revocation use).

[Brian Campbell]

@dgtonge also sent this to the IETF OAuth list https://mailarchive.ietf.org/arch/msg/oauth/Z2QXaIPXvP8BIA0by6ktFSoyKK8 which summarizes much of the discussion herein and sums up the consensus of the group during the May 28 call: “We are leaning towards requiring the Authorization Server to accept any of the above values, but recommending that the Client use the issuer value.”

[Brian Campbell]

Pull Request #67 has proposed changes to address this murkiness

[Brian Campbell]

fixing #155 Merged in b_c/modrna-fork/i155 (pull request #67)

Explicitly state the expectations for the audience value when JWT assertion based client authentication is used at the Backchannel Authentication Endpoint to address issue #155 "aud to use in client_assertion passed to Backchannel Authentication Endpoint

Approved-by: Joseph Heenan [e-mail]

→ <<cset 3529e2c9b1c9>>

[Brian Campbell]

fixing #155 Merged in b_c/modrna-fork/i155 (pull request #67)

Explicitly state the expectations for the audience value when JWT assertion based client authentication is used at the Backchannel Authentication Endpoint to address issue #155 "aud to use in client_assertion passed to Backchannel Authentication Endpoint

Approved-by: Joseph Heenan [e-mail]

→ <<cset 3529e2c9b1c9>>