Document when FE flow is applicable with regards to involved devices #256
Conversation
Add hint on consumption device = target device
Elisabeth-Ericsson
requested review from
jpengar,
AxelNennker and
sebdewet
as code owners
|
I hope that misunderstandings regarding OIDC Authorization Code Flow were removed by "Agreed conclusion statement about auth method in Auth Code Flow #253" A quote from the conclusion:
I created several PRs that try to remove that "limit" e.g. #244 We created CAMARA Security and Interoperability Profile to clarify and add new meaning to e.g. OIDC and e.g. "abused" scope to introduce "purpose as a scope". @shilpa-padgaonkar proposal to introduce a new purpose parameter would have been a "cleaner" solution, but that was rejected because suppliers prefer implementing standards and are reluctant to add new parameters. If ICM decides that e.g. |
There was a problem hiding this comment.
@Elisabeth-Ericsson I guess this clarification is still being added under Spring25 scope, where network-based auth must be used in Auth Code Flow. Right?
| @@ -58,6 +58,7 @@ The list below introduces several key concepts: | |||
| - `Resource Server`: the server that exposes protected resources to Applications. The Resource Server requires a valid access token to be provided before allowing access to the protected resource. | |||
| - `Scope`: the OpenID Connect scope which maps one or more protected resources, some scopes may require processing of Personal Data. | |||
| - `Subscriber`: the mobile subscriber of the Operator. The Subscriber is usually also the End-User, but this is not always the case. For example, a parent may be the Subscriber of a mobile subscription for their child, the End-User. | |||
| - `Target Device`: the device, which is the main resource (target) impacted by an API call and for which consent might need to be collected from resource owner. | |||
There was a problem hiding this comment.
To me the Target Device is the Consumption Device which is already defined in the document. And the access token will be associated the network authenticated identifier corresponding to the Consumption Device. It has been clarified as well in the profile ...CAMARA REQUIRES API Providers to use network-based authentication in the Authorization Code Flow. Therefore, access tokens are issued for the network authenticated identifier.
So, IMHO, you should refer to the Consumption Device instead.
You may need somehow to make your point about the differences between Consumption and Target device clearer.
There was a problem hiding this comment.
| - `Target Device`: the device, which is the main resource (target) impacted by an API call and for which consent might need to be collected from resource owner. | |
| - `Target Device`: the device that is the primary resource (target) affected by an API call, and for which Consent may need to be obtained from the Resource Owner. |
| - No front-end developer software in user device | ||
| - Back-end services (e.g. bank BE anti-fraud validation using MSISDN). | ||
| - Off-net scenarios (no mobile connection) | ||
| - Device connected to WiFi | ||
| - Device without UI (IoT) | ||
| - Note: Consumption device and target device of subsequent API call(s) can be different, access token is generated for the target device |
There was a problem hiding this comment.
I think this is already clarified by line 278 If some use case(s) for an API point to "Off-net" scenarios and where Consumption Device and authentication devices could be different, the Backend flow should be used.. Isn't it?
There was a problem hiding this comment.
By definition, in an Auth code flow, the consumption device is the same as the authentication device. And CIBA is exactly the flow to use when this is not the case.
| @@ -84,6 +85,7 @@ This section describes the authorization flows that can be used to access CAMARA | |||
| Note: In cases where Personal Data is processed by a CAMARA API, and Users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of Three-Legged Access Tokens is mandatory. | |||
|
|
|||
| #### Authorization Code Flow (Frontend Flow) | |||
| The authorization code flow is only applicable if the consumption device, which initiates the process of obtaining a Three-Legged-Access token from the Authorization Server, is also the target device of the intented Network API call(s) . | |||
There was a problem hiding this comment.
| The authorization code flow is only applicable if the consumption device, which initiates the process of obtaining a Three-Legged-Access token from the Authorization Server, is also the target device of the intented Network API call(s) . | |
| The Authorization Code Flow is only applicable if the Consumption Device that initiates the process of obtaining a Three-Legged Access Token from the Authorization Server is also the Target Device of the intended CAMARA API call(s). |
| - On-net (with mobile connection) & application front-end (with embedded browser) | ||
| - Off-net scenarios using refresh_token, as long as there was a connection when the first access_token was requested. | ||
| - Note: Consumption device must be equal to target device of subsequent API call(s). |
There was a problem hiding this comment.
| - Note: Consumption device must be equal to target device of subsequent API call(s). | |
| - Note: The Consumption Device must be equal to the Target Device of subsequent API call(s). |
This would be already clarified in line 88, wouldn't be?
|
|
||
|
|
||
| #### CIBA flow (Backend flow) | ||
| The CIBA flow is applicable if the consumption device is equal to or different from the target device of the intented Network API call(s). |
There was a problem hiding this comment.
| The CIBA flow is applicable if the consumption device is equal to or different from the target device of the intented Network API call(s). | |
| The CIBA flow is applicable if the Consumption Device is equal to or different from the Target Device of the intended CAMARA API call(s). |
I find this a bit confusing. May not be necessary...
Yes, exactly |
What type of PR is this?
What this PR does / why we need it:
There is some misunderstanding about Authorization code flow, a.k.a. FE flow.
It is important to clarify that OIDC authorization code flow is meant to authorize the client/device, which originates the authorization code flow request. This is independent of whether an optional login_hint (e.g. an operator token) is provided or not. The access code generated for such a request (and the resulting access token) are ONLY applicable to API calls, where the target device of the API call is the same device, which has sent in the authorize request earlier.
Authorization code flow must not be abused by indicating an identifier in the optional login_hint, which deviates from the device, which starts the flow.
Which issue(s) this PR fixes:
Fixes #255
Fixes #
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.