Allow to use operator token for device authentication in OpenID Auth code flow

[Elisabeth-Ericsson]

Problem description With issue #145 it was agreed to allow using the operator token for device authentication by passing this token as value in the /bc_authorize request as 3rd option for -loginhint, in addition to tel and ipport. This extension is only added for CIBA flow. However, also authorization code flow would greatly benefit from the ability to pass the operator token. It shall be possible to leverage the -loginhint parameter in the /authorize request and lower the burden on Authorization server to convert an IP address to an MSISDN.

Possible evolution Proposal is to allow loginhint parameter in the authorization code flow authorization request and extend the description in the CAMARA-Security-Interoperability.md (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md) as follows:

Authorization code flow allows the client to use id_token_hint or login_hint as a hint in the authentication request. The client shall be enabled to use the optional login_hint. If used, the login_hint must be populated with one of the 3 formats described in "Format of login_hint" section (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#format-of-login_hint)

Alternative solution

Additional context

[AxelNennker]

The new format was added in https://github.com/camaraproject/IdentityAndConsentManagement/pull/218 The format section applies to all flows. So, operator token support is already part of CAMARA. CIBA and OIDC authorization code flow.

[jpengar]

The new format was added in #218 The format section applies to all flows. So, operator token support is already part of CAMARA. CIBA and OIDC authorization code flow.

I disagree as mentioned here: https://github.com/camaraproject/IdentityAndConsentManagement/issues/191#issuecomment-2301498137 and here https://github.com/camaraproject/IdentityAndConsentManagement/issues/215#issuecomment-2470478556

This issue was originally intended to clarify the authentication method for the Auth Code flow as defined by CAMARA today. I don't see operator tokens in the scope of this issue discussion.

Also, the use of operator tokens is something that will be discussed and included in Spring25 and not in the current Fall24 meta-release. CAMARA has so far defined an additional possible value for the operator token as login_hint (besides MSISDN and IP), which CAMARA has so far only discussed for CIBA. The login_hint has never been discussed for the auth code flow, because it is not needed, since the subscription identity is known anyway from network-based authentication. ...

[jpengar]

@Elisabeth-Ericsson Could you please provide more details on the benefits of using the operator token as a login hint in the Auth Code flow? If the Auth Code flow is used, the network auth can still resolve the corresponding subscription identifier. The operator token is another alternative in CIBA for identifying a user by MSISDN or IP address. When an operator token is obtained, the API consumer could just use CIBA to obtain an access token. Operator tokens also need to be validated.

It is also important to note that any information such as IP, MSISDN or the operator token should not be included in the request URL as query parameters for security purposes. In order to achieve this, it may be necessary to utilise the request object.

[AxelNennker]

Also, the use of operator tokens is something that will be discussed and included in Spring25 and not in the current Fall24 meta-release. CAMARA has so far defined an additional possible value for the operator token as login_hint (besides MSISDN and IP), which CAMARA has so far only discussed for CIBA. The login_hint has never been discussed for the auth code flow, because it is not needed, since the subscription identity is known anyway from network-based authentication.

The API Subject (subscription identity) is associated with the operator token. So, no need for network-based authentication.

[AxelNennker]

@Elisabeth-Ericsson Could you please provide more details on the benefits of using the operator token as a login hint in the Auth Code flow? If the Auth Code flow is used, the network auth can still resolve the corresponding subscription identifier. The operator token is another alternative in CIBA for identifying a user by MSISDN or IP address. When an operator token is obtained, the API consumer could just use CIBA to obtain an access token. Operator tokens also need to be validated.

The operator token can contain all the subscription information the MNO's entitlement server has access to. MSISDN, IMSI, IMEI, ... That is why the operator token is encrypted.

It is also important to note that any information such as IP, MSISDN or the operator token should not be included in the request URL as query parameters for security purposes. In order to achieve this, it may be necessary to utilise the request object.

Why do we accept the tel:MSISDN in CIBA requests as an login_hint URL parameter if that is a security concern?

A signed and potentially encrypted request object is preferable because URL parameters are sometimes logged and they have no integrity protection. I recommend to always use signed request objects.

[Elisabeth-Ericsson]

There are several benefits when allowing the login_hint as described in OIDC Auth code flow: 1) Supporting the login_hint parameter in the authorization code flow allows to overcome the burden of Network authentication based on IP. The IP might be nat'ed (if the authorization server is deployed ouside of CSP's internal NW). The translation of nat'ed IP to internal IP is cumbersome and not always unique. 2) Avoid security problem: For IP to MSISDN translation it is a common method to let the gateway enrich the MSISDN in the header. This must only happen when contacting the authorization server, but not for other server targets. Nevertheless, this is a security hole by itself. It is dangerous to assume that all gateways can properly distinguish. 2) Performance benefit:The operator token can include encrypted MSISDN and or IMSI information, which can be extracted by the authorization server by one call to the entitlement server and used for consent check. 3) Consistency between the two 3-legged flows: authorization code flow and CIBA flow + standard compliance

[eric-murray]

@AxelNennker, @jpengar I agree with you both!

I agree with Axel that CAMARA already "allows" login_hint to be used for authorisation code flow (because OIDC core allows it, and CAMARA do not say otherwise), But I also agree with Jesús that CAMARA have not defined any use case that requires use of the login_hint parameter for authorisation code flow. Vodafone's own implementation will ignore this parameter, if present.

@Elisabeth-Ericsson, @AxelNennker I still don't understand how an operator token in a login_hint provided for the /authorize endpoint will in any way "authenticate" the end user device (UE).

If "device A" requests and receives an operator token, which is then stolen and used in the authentication (/authorize) request from "device B", how is the network operator expected to know that the authentication request has not come from "device A" if they are NOT using network authentication? Maybe you could explain.

[AxelNennker]

I think it does not really matter that VF ignores login_hint=operator_token: because the client would not have gotten an operator token in the first place because VF does not issue operator tokens for that client. That is probably true for all operators and all clients if they do not support operator token, I think.

I heard that VF does not support consent collection in any front-end flow as described in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md . Please correct me if that hearsay is wrong. That, if true, would be an example of something ICM provides guidelines for but not all operators support that feature. It is not the only example where we describe something in ICM but leave it to the onboarding process to tell the API consumer that e.g. CIBA is the only supported flow. I think there is no harm done. Although I wished most operators would support consent collection and prompt=consent.

[eric-murray]

@AxelNennker My point was that Vodafone ignore any login_hint parameter in the authorisation code flow, irrespective of its contents. Whilst we do not support operator tokens, I'm pretty sure we have devices that support telephone numbers and IP addresses. But even then, we ignore the login_hint, because it is not needed.

If any API provider is NOT ignoring the login_hint if present in the CAMARA authorisation code flow, I'd be interested to know what they are doing with it.

[DT-JensPoeschl]

Usecase for MSISDN as login_hint: For KYC fill in on cross devices e.g. Desktop or Tablet in a WIFI environment, user consent for such an API needs always user authentication. In this case, network authentication is not possible. SMS OTP would be a standard for this. For KYC fill in, there has to be done some look ups/ Eligibility Checks e.g. Business Customer Y/N, More than one MSISDN per account Y/N before you are redirect the customer to a MSISDN request webpage for SMS OPT . Without MSISDN as Login_hint, you are not able to do eligibility checks before you start any redirect to any CSP webpage.

[eric-murray]

@DT-JensPoeschl Sure - network authentication fails because the connection is over WiFi, and so you resort to out of band authentication using something like SMS OTP. This would also be a valid use case for the operator token, as the token itself in a login_hint cannot be trusted any more than the MSISDN.

Alternatively, as the application knows the device is connected via WiFi, it could have made the KYC Fill-In API request using CIBA. The authorisation code flow is adding nothing to the use case here other than latency.

But back to the proposal of @Elisabeth-Ericsson for CAMARA to explicitly document use cases of login_hint for the authorisation code flow. So I can understand that an operator token can act in exactly the same way as MSISDN does for your scenario - it allows the network operator to work out who to send the SMS OTP to.

But in no way does it "authenticate" the device, even though it will be harder to send a false operator token than a false MSISDN.

[jpengar]

I believe there may be a misunderstanding regarding the role of the operator token in CAMARA. It seems that there is an assumption that possessing the token equates to authenticating the device. In the context of CAMARA, where the operator token is provided as a login hint, it should be noted that this does not actually authenticate the device. The token is simply a means of identifying a device based on its contents. However, there is no guarantee that the token is not being used by a third party, or used in a different device from the one used to obtain the operator token, etc...

The proposal to use the Authorization Code flow, passing the operator token as a login_hint and considering that sufficient for authenticating the device, is not an optimal solution in my view. It would be necessary to validate the login_hint against the actual authentication mechanism (in the case of the Authorization Code flow in CAMARA, this would be network authentication). Based on the outcome of the aforementioned validation, the Auth server would then be able to determine whether to generate an error if the operator token does not match the authenticated device, to ignore the operator token in the event of discrepancies, or to pursue an alternative course of action. It is important to note, however, that CAMARA has not yet defined any of these potential actions for login_hint in the auth code flow. Given that the operator token would still require validation, I believe that the operator token's utility is limited to CIBA.

@Elisabeth-Ericsson additionally asserted that this approach addresses specific scenarios, such as when a device is connected to a Wi-Fi network or roaming with local breakout (AFAIK the majority of operator services are currently available with Home Routing, where the IP address will correspond to the home network). However, CAMARA ICM ruleset recommends the use of the Authorization Code flow for on-net scenarios, where the device is connected to the operator's network. For other cases, such as when the device is off-net, the correct solution is to use CIBA. In situations like Number Verification, which requires the Authorization Code flow, if the device is on Wi-Fi, it simply won’t work—that’s by design. Number Verification is specifically intended to validate against the mobile network, which is the value proposition of that API.