camaraproject / NumberVerification

Repository to describe, develop, document and test the Number Verification API family
Apache License 2.0
16 stars 21 forks source link

Include authentication policy for Number Verification #154

Open jgarciahospital opened 1 week ago

jgarciahospital commented 1 week ago

Problem description

The objective of Number Verification API is being able to authenticate the device of the customer for ensuring that is using the line associated with the phone number that the third party or application is using as identity.

For such purpose, the API needs to validate the connection (current method) or the SIM (evolution towards Operator Token TS.43) during the authentication process, to later validate that token associated to the actual line identifier with the one provided by the developer in the API request.

Based on that purpose, it is expected that the developer will trigger a new authentication process any time that the API is to be called, ensuring that a proper identification of the line/SIM over the current device is always done before the API call.

One of the use cases to be controlled/avoided is a device changing the SIM card and reusing a token created with the previous SIM: the previous token (linked to the mobile phone number of the old SIM card) would be the one used for the Number Verification evaluation, which is not correct.

Expected action

Include security policy in the API description to ensure that:

Text proposal (inclusion of point 2):

**(1):** Authentication must be automatic without any user interactions. Authentication methods such as SMS OTP or user/password are incompatible, as the goal is to validate the mobile phone number that is accessing the App. So it is required to be authentication via mobile network and without the user being involved. the use of parameter prompt=none, as described in **[OIDC Connect](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)**, ensures no user interaction.

+**(2):** Authentication is the core of this service API, ensuring that the phone_number retrieved or verified is correct and according to the current SIM or network connection. For that puspose, this API includes a security mechanism to avoid token re-usage and a short time expiration policy to ensure that authentication is valid by the moment the API is consumed.

**(3):** The way in which the phone_number is retrieved depends on the implementation. For example, access token may be a self contained encrypted JWT, so API can decrypt and identify phone_number. Some other implementations might request the phone_number associated to the token from Authserver.
AxelNennker commented 4 days ago

Add DPoP

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#secti:~:text=Authorization%20and%20resource%20servers%20SHOULD,%C2%B6

Authorization and resource servers SHOULD use mechanisms for sender-constraining access tokens, such as Mutual TLS for OAuth 2.0 [RFC8705] or OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449] (see Section 4.10.1), to prevent misuse of stolen and leaked access tokens.