-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New specific 403 token error and guidelines alignment #19
New specific 403 token error and guidelines alignment #19
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look good for me but a question: do you think same must done for SIM Swap or is it a number verification specific?
Here we are using just 3-legged token for both endpoints but in Sim Swap we have Client Credentials as well. I'll talk to @jlurien and see how we can align the errors there. Thank you @bigludo7. |
In SIMSwap we have client_redentials and 3_legged, and also msisdn is required as input, while here I see that it is not, so for SIM Swap only would make sense to validate that, when using 3_legged, if access_token is linked to a different MSISDN than the one provided in the request body, then reject the request. We could add an error for that, but with an appropriate description. |
The guideline for errors has been changed today and now status is an integer instead of a string: camaraproject/WorkingGroups#143 I'm going to update the branch and include this change as well :) |
Thanks for the clarification. So probably no hurry to add this for simswap as it will be used for one specific UC and bring some confusion. |
Dear @DT-DawidWroblewski @bigludo7 I also included a fix to an operationId and description that we had missed in the first version. Please review and merged if you find everything ok. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look good for me
Kindly reminder: @DT-DawidWroblewski could you please review and merge this PR? |
@@ -28,7 +28,7 @@ Two endpoints are defined in Number Verification API: | |||
|
|||
**Authentication** | |||
|
|||
Security access keys such as OAuth 2.0 3-legged Access Tokens used by Client applications to invoke this API with dedicated scope. Client must authenticate via IP to use this service. | |||
Security access keys such as OAuth 2.0 3-legged Access Tokens used by Client applications to invoke this API with dedicated scope. Client **must authenticate via IP** to use this service. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GSMA IDG works currently on alternatives to data session, that is required to fulfill Number Verify. Additionally, I don't see this as a must, because some MNOs use tokens that work "like IP address", so no IP address is shared between the client and MNO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edited. Please check it out.
@@ -42,12 +42,12 @@ paths: | |||
post: | |||
tags: | |||
- Phone number verify | |||
summary: Verifies if the received hashed phone number matches the phone number associated with the access token | |||
summary: Verifies if the received hashed/clear phone number matches the phone number associated with the access token |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
plain text looks better than clear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edited here and couple of more pleaces.
- Client authentication was not via mobile network. In order to check the authentication method, AMR parameter value in the 3-legged user's access token can be used and make sure that the authentication was not either by SMS+OTP nor username/password (`{"code": "NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP","message": "Client must authenticate via IP to use this service"}`) | ||
- Phone number cannot be deducted from access token context.(`{"code": "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT","message": "Phone number cannot be deducted from access token context"}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not so convinced about the approach that we share info about the context. Can we simplify the response and use just 401 Unauthorized, invalid_token?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 401 is unauthenticated and in this case the user has authenticated but it's kind of forbidden because they autheticated using a wrong method for example, and so the token lacks informations that is needed to go on with the process. We're just saying that the token is not what it's supposed to be and it can be helpful for the developer. I prefer 403 to 401. Specific errors are specially to give some more information and telling why they're not allowed to do something and they're more developer-friendly in general.
Dear @DT-DawidWroblewski did you get a chance to take a look to the comments and changes that you had asked for? |
- GET /number-verification/v0/device-phone-number : Returns the phone number associated with the access token so API clients can verify the number themselves. | ||
|
||
**Authentication** | ||
|
||
Security access keys such as OAuth 2.0 3-legged Access Tokens used by Client applications to invoke this API with dedicated scope. Client must authenticate via IP to use this service. | ||
Security access keys such as OAuth 2.0 3-legged Access Tokens used by Client applications to invoke this API with dedicated scope. Client **must use network based authentication methods** to use this service. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good
@@ -50,7 +50,7 @@ Following table defines API endpoints of exposed REST based for Number Verificat | |||
|
|||
| **Endpoint** | **Operation** | **Description** | | |||
| -------- | --------- | ----------- | | |||
| POST /number-verification/v0/verify | **Request to verify a number** | Create request in order to verify if the specified phone number (clear or hashed format) matches the one that the user is currently using | | |||
| POST /number-verification/v0/verify | **Request to verify a number** | Create request in order to verify if the specified phone number (plain text or hashed format) matches the one that the user is currently using | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@@ -61,7 +61,7 @@ Following table defines API endpoints of exposed REST based for Number Verificat | |||
| -------------------------- | | |||
| **HTTP Request**<br> POST /number-verification/v0/verify<br>**Query Parameters**<br> No query parameters are defined.<br>**Path Parameters**<br> No path parameters are defined.<br>**Request Body Parameters**<br> **One of:** <br> **phone_number**: A phone number belonging to the user. 'E164 with +' format.<br> **hashed_phone_number**: Hashed phone number. SHA-256 (in hexadecimal representation) of the mobile phone number in 'E164 with +' format. | |||
|
|||
<br>**Response**<br> **200: OK**<br> Response body: <br>**device_phone_number_verified** : Boolean <br> **400:** **INVALID_ARGUMENT**<br> **401:** **UNAUTHENTICATED** <br> **403:** **PERMISSION_DENIED** <br> **403:** **NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP** <br> **500:** **INTERNAL**<br> **503:** **UNAVAILABLE**<br> **504:** **TIMEOUT**<br> | |||
<br>**Response**<br> **200: OK**<br> Response body: <br>**device_phone_number_verified** : Boolean <br> **400:** **INVALID_ARGUMENT** <br> **401:** **UNAUTHENTICATED** <br> **403:** **PERMISSION_DENIED** <br> **403:** **NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP** <br> **403:** **NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT** <br> **500:** **INTERNAL**<br> **503:** **UNAVAILABLE**<br> **504:** **TIMEOUT**<br> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we say that we use network authentication for Number Verify should we give 403 NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP?
@@ -70,7 +70,7 @@ Following table defines API endpoints of exposed REST based for Number Verificat | |||
| -------------------------- | | |||
| **HTTP Request**<br> GET /number-verification/v0/device-phone-number<br>**Query Parameters**<br> No query parameters are defined.<br>**Path Parameters**<br> No path parameters are defined.<br>**Request Body Parameters**<br> No body | |||
|
|||
<br>**Response**<br> **200: OK**<br> Response body: <br>**device_phone_number** : The device phone number associated to the access token. 'E164 with +' format. <br> **400:** **INVALID_ARGUMENT**<br> **401:** **UNAUTHENTICATED** <br> **403:** **PERMISSION_DENIED** <br> **403:** **NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP** <br> **500:** **INTERNAL**<br> **503:** **UNAVAILABLE**<br> **504:** **TIMEOUT**<br> | |||
<br>**Response**<br> **200: OK**<br> Response body: <br>**device_phone_number** : The device phone number associated to the access token. 'E164 with +' format. <br> **400:** **INVALID_ARGUMENT**<br> **401:** **UNAUTHENTICATED** <br> **403:** **PERMISSION_DENIED** <br> **403:** **NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP** <br> **403:** **NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT** <br> **500:** **INTERNAL** <br> **503:** **UNAVAILABLE**<br> **504:** **TIMEOUT**<br> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we say that we use network authentication for Number Verify should we give 403 NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP?
@@ -88,9 +88,10 @@ Following table provides an overview of common error names, codes, and messages | |||
|2 |401 | UNAUTHENTICATED | "Request not authenticated due to missing, invalid, or expired credentials" | | |||
|3 |403 | PERMISSION_DENIED | "Client does not have sufficient permissions to perform this action" | | |||
|4 |403 | NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP | "Client must authenticate via IP to use this service" | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we say that we use network authentication for Number Verify should we give 403 NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP?
- Client authentication was not via mobile network. In order to check the authentication method, AMR parameter value in the 3-legged user's access token can be used and make sure that the authentication was not either by SMS+OTP nor username/password (`{"code": "NUMBER_VERIFICATION.USER_NOT_AUTHENTICATED_BY_IP","message": "Client must authenticate via IP to use this service"}`) | ||
- Phone number cannot be deducted from access token context.(`{"code": "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT","message": "Phone number cannot be deducted from access token context"}`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@@ -278,11 +281,11 @@ components: | |||
content: | |||
application/json: | |||
schema: | |||
$ref: '#/components/schemas/NotAuthenticatedByIpPermissionDenied' | |||
$ref: '#/components/schemas/PhoneNumberVerificationPermissionDenied' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@@ -310,7 +313,7 @@ components: | |||
examples: | |||
response: | |||
value: | |||
status: "500" | |||
status: 500 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@@ -338,7 +341,7 @@ components: | |||
examples: | |||
response: | |||
value: | |||
status: "503" | |||
status: 503 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
@@ -366,7 +369,7 @@ components: | |||
examples: | |||
response: | |||
value: | |||
status: "504" | |||
status: 504 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
This PR is to solve Issue #18.
Please review and share your feedback.
Thank you.
The errors status will be changed also into integer.