search

camaraproject / IdentityAndConsentManagement

Repository to describe, develop, document and test the Identity And Consent Management for CAMARA APIs
Apache License 2.0
18 stars 30 forks source link

Clarify role and usage of id token #136

Closed Elisabeth-Ericsson closed 1 month ago

Elisabeth-Ericsson commented 4 months ago

Problem description ID tokens are meant for being evaluated by the application requesting the token. Since CAMARA APIs are not always directly called by applications, but also by aggregators, it must be specified, what should happen to the id token. As specified by the OIDC standard and the discussion on open_id scope below, the id token is mandatory to be returned. Is the ID token just meant as proofpoint for having successfully authenticated the user (device) ? Or is the id token to be provided to the app by the aggregator ? Is the id token meant to be sent as id_token_hint ?

Expected action Add clarification to the OIDC profile document https://github.com/camaraproject/IdentityAndConsentManagement/pull/121

Additional context see some documentation on id token in https://github.com/camaraproject/IdentityAndConsentManagement/pull/113/files

shilpa-padgaonkar commented 4 months ago

https://github.com/camaraproject/IdentityAndConsentManagement/pull/121/files#r1506463615

133

AxelNennker commented 3 months ago

@Elisabeth-Ericsson yes, I think that the id token is better than login_hint if the client already has an id token. It is still valuable to define the format for e.g. tel in login_hint, if the client does not have an id token. Even if the id token is expired, it is signed by the AZ and so the AZ can validate that signature and be sure that the values inside were issued by itself and thus are in a format the AZ recognizes.

In an onboarding scenario there is no id token and login_hint is the only thing that the client can send. Any IP-2-MSISDN mechanism the operator does are independent of whether login_hint or id_token_hint are sent.

AxelNennker commented 2 months ago

Hi @Elisabeth-Ericsson,

I wrote my opinion on login_hint and id_token_hint in the previous comment.

Regarding additional context: the section on id_token mostly repeats what OIDC specifies on claims and no differences to OIDC are marked there. I do not know what readers learn form repeating the standards. The following section is in addition to OIDC.

The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT). ID Tokens MUST be signed by Authorization Server using JWS.

Do you want that or a similar section in #121 ?

To the other questions:

Is the ID token just meant as proofpoint for having successfully authenticated the user (device) ? Or is the id token to be provided to the app by the aggregator ?

If the client sends an authentication request to the aggregator speaking OIDC then the aggregator returns an id token to the client. Otherwise the protocol is not OIDC.

Elisabeth-Ericsson commented 2 months ago

Hi @AxelNennker , yes a section describing the purpose of the login_hint_token and/or the id_token_hint. Also we need to clarify when this parameter is allowed. The description should be included in #121.
But the problem is a bit broder.

For Authcode flow (extended by OIDC) the id_token_hint is an optional request parameter and should be supported (see https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml). For CIBA: According to the CIBA documentation, id token hint and login_hint_token are optional request parameters and should be supported. We found that different AuthZ support one or the other parameter, but not necessarily both (e.g. Keycloack supports only login_hint_token for CIBA).

Also we found that there is an initiative from GSMA to standardize a carrier token as an extension of TS 43, which is delivered to the device and identifies the device/subscription. This carrier token should be pushed to Camara and used for Number Verify (initially). There is a problem now since the Authcode flow used for NumberVerify does not support login_hint_token yet. The id_token_hint is not suitable in this context.

Our proposal is to trigger an extension and allow login_hint_token also for the authcode flow.

jpengar commented 2 months ago

Hi @Elisabeth-Ericsson @AxelNennker, my 2 cents:

  1. AFAIK, CAMARA has not defined any specific use cases for id_token beyond those defined in the OIDC standard.
  2. CAMARA does not know anything about aggregation flows. From the perspective of the CAMARA profile, there is an API client, which can potentially be an aggregator, an application, etc. So I think what an aggregator has to do with an id_token is outside the scope of CAMARA.
    • We can't assume that an aggregator has to forward an id_token to the client application. For example, you may have an aggregator using a wholesale model where the aggregator exposes its own services and interfaces to developers, but those services are then somehow enriched with CAMARA API calls in the background. In this context for example it makes no sense to forward any id_token to the client application.
    • And on the other hand, CAMARA could also be used in other contexts than Opengateway.
AxelNennker commented 2 months ago

I added a section ID Token before ID Token Sub Claim. Please see https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md#id-token

@Elisabeth-Ericsson please propose text if you think the text should say more about ID Token. I would like the id_token_hint discussion to be in that issue. We seem to be able to close that one as well.

AxelNennker commented 2 months ago

New text on "missing openid value in scope parameter" which mentions the role of id token in OIDC https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md