CIBA - is AS required to issue an access token?

[Joseph Heenan]

The CIBA spec https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html#rfc.section.10.1.1 currently says:

After receiving and validating a valid and authorized Token Request from the Client and when the end-user associated with the supplied auth_req_id has been authenticated and has authorized the request, the OpenID Provider returns a successful response as specified in Section 3.1.3.3 of [OpenID.Core].

https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse states:

After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token

So as written, CIBA appears to require an access token to be returned. (I’m unsure if this is deliberate.)

Discussion with Petteri revealed they have a use case where only the id_token is required, so they don’t return an access token. It would be good to clarify if this is permitted (my main interest as usual is what checks the conformance suite should be making).

[Rob Otto]

I’d argue that since CIBA is an OpenID Connect flow it should always return an Access Token in order to remain consistent with the behaviour of the other OIDC and OAuth flows.

[Joseph Heenan]

Thanks Rob. The counter argument would be that response_type=id_token doesn’t issue an access token either. (I’m not pushing in either direction here, just pointing out the similarities )

[Rob Otto]

fair point! I’ve never encountered it in practice though. Have you?

[Joseph Heenan]

I can’t say I personally have, but Petteri has a use case for it.

Conceptually, it seems unnecessary (and hence bad by the general security principle of minimisation) to issue an access token if the client has no use for it. It would raise other questions though, like it is the RP or the OP that decides whether to issue an access token or not - and if it’s the RP, how does it communicate that wish to the server in a CIBA flow.

Conversely, for OpenID Connect Core certification it’s required that the user info endpoint is supported and hence the OP must be able to issue access tokens. I am not sure if the modrna working group would carry over that principle though, or decide (as the FAPI WG essentially did) that user info endpoint is not required for certification.

[Rob Otto]

I think you may have hit the nail on the head here, Joseph. The real issue is perhaps having no mechanism under CIBA for the RP to specify what it needs from the OP. Until and unless that mechanism exists, we may have to be more prescriptive about what must be returned by all OP’s in the name of interoperability? I foresee much confusion otherwise.

Edit: your comment about minimisation is, of course, 100% valid notwithstanding the above.

[Brian Campbell]

https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse also says “parameters in the successful response are defined in Section 4.1.4 of OAuth 2.0 [RFC6749]” and 4.1.4 in turn points to https://tools.ietf.org/html/rfc6749#section-5.1 for a successful response which has access_token as REQUIRED. This stuff builds on OAuth and access_token is required from the token endpoint on successful request so the answer is yes.

[Dave Tonge]

We discussed this on the call and agreed that although there are use-cases where no access token is needed it is not related to CIBA. i.e. such use-cases apply to auth code flows as well. We also discussed that because CIBA and OIDC build on RFC6749 which requires access tokens to be returned from the token endpoint it wouldn’t be easy to define an extension which made that optional. We agreed to close this issue with no changes being made to the spec.