Proposal to protect the "OAuth2 AuthCode Grant authorisation request" endpoint

[mhfoo]

Problem description

Referring to the following sequence diagram,
is the endpoint "OAuth2 AuthCode Grant authorisation request (prompt=none&redirect_uri)" on the AuthServer protected?

Possible evolution
Proposal to have a one-time use token to prevent abuse of this un-protected endpoint on AuthServer.
The App Backend will need to obtain this one-time use token from the AuthServer and pass it to the Device App.

Proposal as attached:

[mhfoo]

We are also seeing aggregators using the unprotected API of interaction Number 10 (between UE and Operator's Auth Server) to detect the operator of the SIM card to perform their own version of the Telco Finder.

[mhfoo]

@mhfoo will use a reference diagram from OGW to illustrate aggregators

[mhfoo]

Standalone Example

Federated Example

[mhfoo]

@mhfoo will append the complete flows for illustration purpose.

[sfnuser]

Problem description

Referring to the following sequence diagram, is the endpoint "OAuth2 AuthCode Grant authorisation request (prompt=none&redirect_uri)" on the AuthServer protected?

@mhfoo - Could you please clarify why this is a problem? The authorization request will also have an associated client_id that the auth server can validate. If it is about general protection of the public authorize endpoint the standard rate limiting, ddos prevention methods should work.

[mhfoo]

@sfnuser
Referencing the above diagram; this is to solve the following points.

1. A bad actor can perform a DDOS attack with multiple Operator Y SIM cards on Operator Y /authorize endpoint - light blue dash route; this is an internal mobile network route without traversing the Internet. The one-time use token will be validated at the Auth Service, and therefore protecting the downstream network nodes.

2. Aggregators are using mobile apps to query different operator /authorize endpoints to discover (at no cost) which operator the SIM card belongs too. The one-time use token will be associated with an Application Backend for charging purposes.

[mhfoo]

Standalone

Federated

@DT-DawidWroblewski as requested above.

[mhfoo]

Standalone:
Proposal.txt

Federated:
Simple Federated Proposal.txt

@DT-DawidWroblewski
Please see attached.

This is based on this tooling: sequencediagram.org
Just need to load the text.

[fernandopradocabrillo]

@mhfoo This proposal is defining a pre-step to the number verification API call, which I believe is in the scope of authN authZ. Perhaps this topic fits better in the I&C working group, as it can be applied to more APIs.

[mhfoo]

@mhfoo This proposal is defining a pre-step to the number verification API call, which I believe is in the scope of authN authZ. Perhaps this topic fits better in the I&C working group, as it can be applied to more APIs.

Yes, agree.
Number verification is the first intended CAMARA API application (for Singtel) to "fix".

Once this sub project does not have any objection or further clarifications. I will raise to both I&C working group and GSMA Open Gateway, Chapter 6.

[fernandopradocabrillo]

Once this sub project does not have any objection or further clarifications. I will raise to both I&C working group and GSMA Open Gateway, Chapter 6.

I think the process should be the other way around. If it is something specific to number verification it makes sense, but this is something generic to all apis. In my opinion the first thing should be to present the proposal to I&C and GSMA and then go to the WG to apply it. It won't do much good if there are no objections here but when it gets to I&C the proposal doesn't fit. Or if there are objections in other subgroups.

[mhfoo]

@fernandopradocabrillo
To my understanding, Authorization Code Flow (Auth Code Flow) is used in the Number Verification APIs. I am not aware if other CAMARA APIs are using this Auth Code Flow.

This proposal is to protect the /authorize endpoint in the Number Verification use case, based on the Auth Code Flow.

The rest of the CAMARA APIs are using CIBA or Client Credentials flows. The OIDC profile is being discussed here

I will raise in I&C and GSMA in due time, waiting until the baseline OIDC profile is defined.

FYI: This will impact the CAMARA certification for Number Verification, as this is a security concern.

[AxelNennker]

@fernandopradocabrillo To my understanding, Authorization Code Flow (Auth Code Flow) is used in the Number Verification APIs. I am not aware if other CAMARA APIs are using this Auth Code Flow.

Hi @mhfoo
All Camara APIs that need user consent MUST use authorization code flow.

If user consent is not "needed", for whatever reason, the API is protected by oauth2 client credentials flow.
NumberVerify has this https://github.com/camaraproject/NumberVerification/blob/release-0.3.1/code/API_definitions/CAMARA/number_verification.yaml#L147

  securitySchemes:
    three_legged:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration

And the same security scheme in their main branch https://github.com/camaraproject/NumberVerification/blob/main/code/API_definitions/number_verification.yaml#L158 Just the name changed.

  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration

Regarding prompt=none:

OIDC says

"An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request."

And

When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not

So, normal non-telco AZ need a way to determine who the sub is. This is either done through cookies or a id_token_hint.
Neither is mentioned in the issue. How does the AZ determine the sub and whether they are logged-in?
If there is neither a id_token nor a cookie, then the AZ can return an error because the conditions of the request are not fulfilled.

If the client already has an id_token, then the id_token was granted by the same AZ and spraying all known AZ with prompt=none requests is unnecessary because the requester already knows the answer the home-grown telco-finder might solve.

Does requiring the id_token solve this issue?

Or am I missing the problem?

[diegogonmar]

@AxelNennker why you say that AuthCode is a must in every CAMARA API if consent is needed? What about CIBA? Please clarify your message as is asserting some points that may cause confusion
Also the sentence about Client Credentials if consent is not needed may be misleading.
I'd suggest to better refer to Identity&Consent documentation, where this information is included.

@mhfoo regarding this API, yes AuthCode was set as the only valid option as this API is strictly related with silent (network-based) authentication. As indicated here API is to verify the phone number associated with the SIM used in the device connected to the mobile data network.. Other CAMARA APIs can use AuthCode unless otherwise stated in each API indicating a reason not to allow it

[mhfoo]

Hi @AxelNennker :

Agree with @diegogonmar comments above.

Using the following diagram as context.

The following are the concerns:
/authorize endpoint does not require any form of authentication to invoke this API.

1. Any entity can invoke this public API to cause a DDoS attack - light blue dash route
2. A trusted entity (e.g an aggregator) can use this endpoint of multiple different operators to determine the operator of a SIM card, at no cost, without continuing the auth code flow.
   Example: If this endpoint response successfully with a redirect 302, the SIM card belongs to this operator. If this endpoint response with an error, the SIM card may not belong to this operator.

For point 1. above, I believe garciasolero is addressing it in IdentityAndConsentManagement: issue 128

Let's connect in IdentityAndConsentManagement: issue 128.

[mhfoo]

@DT-DawidWroblewski please refer to IdentityAndConsentManagement Issue 128

I agree with the proposal to use RFC9101

Will drop the initial proposal in this issue #71.