Add a section on operator token usage in authorization code flow #238
Conversation
There was a problem hiding this comment.
I believe this is related to Issue #232 and/or an attempt to resolve it, isn't it?. However, as stated in #232 (comment), Telefónica has a different view on this proposal. For further details, please refer to the linked comment.
|
|
||
| Then, two alternatives may occur: | ||
|
|
||
| **Scenario 1**: User Consent is not required or User Consent has already been given (Step 7). The API Exposure Platform will continue the authorization code flow by redirecting to the Application's redirect_uri (api_consumer_callback) and including the authorization code (OperatorCode). |
There was a problem hiding this comment.
So, to be clear:
- if the
/authorizerequest includes the operator token in alogin_hint, and the User associated with that operator token has already given consent for the requested scope and purposes - then the API transaction would proceed with no further interaction with the end user of the device at all?
I had understood that the purpose of mandating support for login_hint in the authorisation code flow was to allow "inband" interaction with the user of the device to get End User consent, using the login_hint only as a "hint" as to the true identity of the End User.
So why is Scenario 1 even an option? Surely this End User interaction should be mandatory when login_hint is included in the authorisation code flow, as their identity will not be known until they do interact.
There was a problem hiding this comment.
As I understand it, adding the operator_token in the login_hint is the equivalent of a network authentication, the operator_token is a proof of authentication of the device (or identification of the SIM card) and it means that as a network authentication, if the consent is already given for this MSISDN (and not revoked), we don't need to wake up the end-user to get it.
There was a problem hiding this comment.
@sebdewet From the CAMARA perspective, the Auth Server receives an /authorize request with a login_hint containing an operator token. What happens if the app developer uses the operator token obtained for the SIM in device A (MSISDN A) in an Auth code flow from device B with a different SIM (MSISDN B)? If consent is granted or not required for MSISDN A, then the Auth server would issue an access token associated with MSISDN A, which is different from the consuming device B. Now, if the app in device B consumes, say, Device Location API, you could end up getting the location of device A instead of B. Or what happens if the operator token is used by another third party? We can agree that an operator token is much harder to misuse than an MSISDN, but provided as a login_hint (without further validation), from a CAMARA perspective it only identifies a device as an IP or an MSISDN when provided as a login_hint.
There was a problem hiding this comment.
In the last ICM call 04/12 it was proposed that tokens be enhanced with attributes such as app IDs or IP addresses in order to improve security.
There was a problem hiding this comment.
Why an app developper would do that ?
The application developer wants to provide and sell a service, if they misuse the operator token, they will not gain from the offered service.
There are certainly cases where this could be interesting for them, and we need to protect against that. In this case, we should think about identifying those cases and only offer the login_hint with the operator token in use cases where we are certain that misuse cannot benefit a developer.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Provide a guideline how an operator token can be used.