Replace Frontend Flow to unify consent collection and reduce latency

[chrishowell]

Problem description The frontend flow uses a completely different mechanism for consent collection than all other CAMARA APIs (that use CIBA). Including consent capture within the frontend flow is also difficult/impossible to implement in practice, as the ASP loads the authorization URL within an API client, rather than in a browser. The frontend flow is also proving to be very slow due to the number of redirects over the mobile network that are required to generate an auth_code.

Possible evolution Ideally we want a single way of collecting consent across all APIs, this would likely be using the CIBA flow.

The identity of the end-user for CIBA APIs is currently provided using a login_hint. In order to support 'frontend' use cases where the end-user's identity needs to be guaranteed we can use a cryptographically secure id_token, supplied to CIBA using the id_token_hint parameter.

Obtaining the id_token can be achieved using the OIDC Implicit Flow (with strict response_type of id_token ONLY) - other response_types MUST NOT be used.

As already proposed for the Frontend Flow, the Implicit Flow can also be extended to use signed requests to ensure the call has been requested by a registered application - this along with state/nonce parameters have been left out for brevity.

[AxelNennker]

1)

The Frontend Flow uses a completely different mechanism for consent collection "different" to what?

2) Please see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-implicit-grant OAuth 2.0 Security Best Current Practice clearly recommend authorization code flow.

In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type "token") or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated

Does your proposal address the concerns raised by OAuth 2.0 Security Best Current Practice?

3)

Consent must be freely given, specific, informed and unambiguous https://gdpr-info.eu/issues/consent/

I do not see how your proposal implements "freely given, specific, informed and unambiguous" better than authorization code flow.

The user credentials at the CSP can easily be stolen in a javascript-based webview inside a mobile app.

I see that doing user consent "right", secure and GDPR compliant, leads to flows that mobile app product owners do not like.

[chrishowell]

1. Different to all other CAMARA APIs, consent collection in the frontend flow is only available during the auth code collection phase, which will likely always be loaded by ASPs within an API client, rather than within a browser; this makes consent collection within this phase impossible, even though that's the only opportunity for the CSP to collect consent in the frontend flow. Different to CIBA, where consent collection is done in the async access_token phase and is decoupled.
2. That advisory/best practice against using implicit flow is for obtaining access_tokens via the implicit flow, NOT id_tokens. As the id_token is not part of the authentication of the resource API that warning is not applicable. The id_token should include a sub that is completely opaque, and so it would not need to be any more private than an auth_code. The advantage of this proposal is that it splits the identification of the end user from consent collection.
3. Consent would be collected within the CIBA flow, the same as all other CAMARA APIs, unifying how consent is collected across all CAMARA APIs is highly desirable.

[sfnuser]

I agree on the process to unify or standardize consent collection. However, the problem statement is still not clear to me. Could you please explain it with details?

Including consent capture within the frontend flow is also difficult/impossible to implement in practice, as the ASP loads the authorization URL within an API client, rather than in a browser. The frontend flow is also proving to be very slow due to the number of redirects over the mobile network that are required to generate an auth_code.

• All standard ID providers like Google, Meta etc. still use the front end flow and the end user is familiar with it.
• Consent collection is an one time process and that necessarily should not increase the latency of frontend flow.

Few related topics to this issue:

• There is also this API proposal to collect consent https://github.com/camaraproject/APIBacklog/pull/67
• CIBA is designed for use cases where the consumption and authentication devices are different and I wouldn't consider it for universal adoption for all use cases https://github.com/camaraproject/Commonalities/issues/259#issuecomment-2253829868

[garciasolero]

Some comments from my side:

1. The number of redirects over the mobile network will be the same for both the authorization code flow and the implicit flow. You will need to resolve the IP in the same way.

2. You are executing two different authorization flows, adding an additional call to bc-authorize, which is not necessary in the authorization code flow. Therefore, a more complex flow is being created, and it will take longer to return the token.

3. The aim of the Number Verification API is for user authentication and authorisation to take place on the same device as the consumption device. In your proposed solution, you decouple authentication from authorisation, and if user consent is required, it would be done out-of-band in the CIBA flow. To me this seems rather artificial and confusing from a user perspective.

4. By splitting the flow into two, there is no guarantee that the CIBA flow will execute immediately after the implicit authentication flow. Therefore, the number verification response is less reliable.

5. I haven’t analyzed it in depth, but I’m not sure it’s 100% secure. For instance, an ID token will be returned even if there is no consent from the user. The ID Token contains information that could identify the user, such as the sub claim.

[chrishowell]

Lots of comments to respond to :D

Some of the intricacies of the pain points are true only when there's an aggregator involved.

On Redirects:

An aggregator cannot expose access tokens provided by a CSP to the ASP, as this would allow the ASP to circumvent the aggregator for the resource APIs; as such, an aggregator must issue their own access tokens. In order to achieve this, the aggregator must be part of the Authorization Code Flow's redirects to capture the auth_code and associate it with some state, so that when the ASP uses the auth_code on the token endpoint they know where to route the request.

The Implicit Flow does not require the aggregator to be present in the redirects, as the id_token is not providing any authentication or authorisation. The CIBA id_token_hint can use the standard iss claim (or a custom claim) to achieve routing when requesting an access token, however auth_codes must be treated as opaque strings.

On Consent Collection

All standard ID providers like Google, Meta etc. still use the front end flow and the end user is familiar with it.

ASPs are very proud of their applications and their user experience, they will not use an API which forces every login journey to be disrupted.

ASPs are not looking for a Google/Meta/etc. experience, they are not using the CSP as their identity provider, only to augment and secure their platform; displaying a browser window (even within their application) is generally not acceptable during the login process.

The vast majority of CSPs and regulatory areas will not require consent collection for login (fraud prevention) purposes, so loading a browser window inside their application for the exception is a serious pitfall - instead they are calling the authorization endpoint from an API client (which will never launch a browser window, and will not allow for consent collection in this flow).

There will be a time where the ASP will have to prepare the end-user for potential consent-collection and disruption to the UX, but it is not every time that they log in.

You are executing two different authorization flows, adding an additional call to bc-authorize, which is not necessary in the authorization code flow. Therefore, a more complex flow is being created, and it will take longer to return the token.

I don't think this would be true in practice, the minimum interval required before obtaining an access token is being ignored by everyone; this is a problem with CAMARA's use of CIBA poll and can be talked about separately. In the meantime, and in practice, a second call from ASP backend is offset by the savings in requests over the mobile network and work required in the aggregator to store/process the auth_code.

By splitting the flow into two, there is no guarantee that the CIBA flow will execute immediately after the implicit authentication flow. Therefore, the number verification response is less reliable.

The identity of the end-user device is captured at the moment auth_code is generated in the Authorization Code Flow, and the moment the id_token is generated in the Implicit Flow. The Number Verification API is only matching that identity against the phone number, and that will always be reliable, it doesn't matter how much time has passed. The "is the phone number still associated with that device" question is left to the ASP's risk appetite for how long they want to continue using an access token generated by an 'old' identity.

I haven’t analyzed it in depth, but I’m not sure it’s 100% secure. For instance, an ID token will be returned even if there is no consent from the user. The ID Token contains information that could identify the user, such as the sub claim

The id_token must only identify the end-user as much as an auth_code does, i.e. the sub must be opaque; otherwise, yes, consent would likely need to be considered.

[garciasolero]

The redirection to the aggregator in the implicit flow will be necessary anyway. The application would need to know which operator to forward the IP authentication request to, and as far as I know, only the aggregators have access to that information.

Regarding authentication/authorization decoupling, you acknowledge that there is a risk, and to mitigate it, you transfer certain responsibilities to the application. This means that the operator is not verifying the number and capturing consent in a 100% secure way.

The sub claim within the id_token, although opaque, identifies the user in both flows, with the slight difference that in the auth code flow it is only be returned if the user has given their consent. On the other hand, in the implicit flow, it is always returned without any user interaction and before the consent check, that is done in the CIBA flow. I think this is an important point.

[jpengar]

If you ask me, I think CAMARA should stick to the existing standard solution based on Auth Code flow. And continue to work on issues like #145 for using a standard solution for an Operator Token. Which seems to me to be the right solution for this and a solution that guarantees privacy and security (based on EAP-AKA, Entitlement Server, etc...). Since I have similar concerns about the proposed alternative to those raised by @garciasolero above.

[chrishowell]

145 is absolutely the way to go to obtain a non-trackable identity (carrier) token longer term (rather than Implicit Flow) that can then be used to obtain an access token, but AFAIK it also will not provide a way of collecting consent from the Operator before returning the identity.

[AxelNennker]

145 is absolutely the way to go to obtain a non-trackable identity (carrier) token longer term (rather than Implicit Flow) that can then be used to obtain an access token, but AFAIK it also will not provide a way of collecting consent from the Operator before returning the identity.

What does "returning the identity" mean?

How consent is collected is not specified in any protocol or flow. OIDC assumes a web-page for consent collection presented by the openid provider to the authenticated user.

What do people in this thread mean by "implicit flow"? Just to be sure, do you mean OAuth2 implicit grant? https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.2 Or OIDC implicit flow? https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth Or something else.

You know that implicit flow has severe security drawbacks, right? Clients should use OIDC authorization code flow with PKCE instead. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-implicit-grant

Are our current or expected clients using implicit flow? Are we assuming they use implicit flow?

[AxelNennker]

1. Different to all other CAMARA APIs, consent collection in the frontend flow is only available during the auth code collection phase, which will likely always be loaded by ASPs within an API client, rather than within a browser; this makes consent collection within this phase impossible, even though that's the only opportunity for the CSP to collect consent in the frontend flow. Different to CIBA, where consent collection is done in the async access_token phase and is decoupled.

I still don't see what "Different to all other CAMARA APIs, consent collection in the frontend flow" means.

OIDC is not a Camara API. OIDC and CIBA and client credentials flow are no Camara network API. They are APIs that decouple authentication and authorization from the API.

[garciasolero]

@AxelNennker,

The proposal refers to the OIDC Implicit Flow, with only response_type=id_token. This flow could be considered secure under certain circumstances by using the nonce parameter (to mitigate replay attacks) and signed requests.

As I mentioned earlier, I think the main problem lies in combining this flow with the CIBA flow and postponing the user's consent to later stages. Without user interaction, personal information is already returned to the application in the id_token. Also, I do not believe that this will reduce the number of requests, but rather increase them, as it requires a call to the bc-authorize endpoint.

[chrishowell]

This proposal was intended to remove the Authorisation Code Flow because it requires too many redirects from the end-user device, which have proved to be far too slow for ASPs in practice. CIBA has its own problems, where even if consent is not required another round trip is required to obtain an access token using the auth_req_id.