Hi Mario, On Mon, Jan 17, 2022 at 10:58:16AM +0100, Mario Loffredo wrote: > Il 17/01/2022 02:07, Tom Harrison ha scritto: >> On Fri, Jan 14, 2022 at 09:19:55AM +0100, Mario Loffredo wrote: >>> Il 11/01/2022 12:03, Tom Harrison ha scritto: >>>> But the relying party must treat the access token as opaque, >>>> regardless of whether it uses JWT or similar. From RFC 9068: >>>> >>>> 6. Privacy Considerations >>>> >>>> As JWT access tokens carry information by value, it now >>>> becomes possible for clients and potentially even end >>>> users to directly peek inside the token claims >>>> collection of unencrypted tokens. >>>> >>>> The client MUST NOT inspect the content of the access >>>> token: the authorization server and the resource server >>>> might decide to change the token format at any time (for >>>> example, by switching from this profile to opaque >>>> tokens); hence, any logic in the client relying on the >>>> ability to read the access token content would break >>>> without recourse. The OAuth 2.0 framework assumes that >>>> access tokens are treated as opaque by clients. >>> >>> [ML] I think that in the sentence above the term "client" refers >>> to the frontend application that is normally used in the classic >>> OIDC pattern. >> >> That's right. A "client" that uses OIDC is referred to as a >> "relying party" in the OIDC context, too. In the draft, the RDAP >> server is a "client" per OAuth 2 and a "relying party" per OIDC. >> >>> In that pattern, the client does not need to inspect the access >>> token because it contains only information useful for the resource >>> server. >> >> I don't understand this point. Even if the (OAuth) client might >> make use of the information in the access token, the (OAuth) client >> is not permitted to inspect it, and must treat it as if it were >> opaque. > > [ML] What I meant to say is that in the OIDC reference interaction > pattern, the RDAP server would act as a Resource Server. An RDAP > client would act as a Relying Party. > > Normally, the RP, that is a frontend for the RS, is a trusted > application and it doesn't need to inspect the access token. On the > contrary, the RS inspects tha access token to make access control > decisions > > based on some claims designed for being included in the access token > such as groups, roles, entitlements. > > In the draft, an RDAP client is normally untrusted so the RDAP > server acts as an RP but we cannot ignore that the RDAP server is > still an RS. > > I think that both the OAuth and the OIDC actors was defined for the > reference pattern so we cannot apply them to the draft pattern > straightforwardly because otherwise we'll face some inconsistencies.
The only difference I can see between the approach used in the draft and the approach described in the OIDC specification is that the relationship between the RDAP server and the RDAP client is maintained by passing the tokens back to the RDAP client, and having the RDAP client include them in requests to the server. I don't think this makes the RDAP server an (OAuth) resource server, or the RDAP client an (OAuth) client. The fact that the RDAP server makes authorisation decisions based on the information provided to it by the OpenID provider doesn't change this. It seems to me to be analogous to an (OIDC) relying party (an (OAuth) client) making authorisation decisions based on the "acr" claim in the ID token (e.g., per the OIDC documentation: "[a]uthentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value"). > For example, now the mostly used access token format is JWT. Such a > format is perfectly consistent with the reference pattern because it > isn't normally exchanged outside a trusted context. > > So, with reference to the draft, we cannot say that the access > token MUST be opaque but we can say that it MUST be treated as > opaque by the RDAP client and, anyway, it MUST NOT include sensitive > information. > > In addition, we cannot say that the RDAP server MUST treat the > access token as opaque because it is normally inspected by the RS. I think updating the document in this way makes it sufficiently different from the standard OAuth/OIDC model that ensuring that it retains all the important properties of those models will be difficult. The fact that the RDAP client gets the ID token and access token is a little unusual as it is (IME), but turning the RDAP server into a sort of hybrid (OAuth) client and (OAuth) resource server, along with guaranteeing the format and claims in an access token, goes quite a bit further than that. This may all be moot, though, if using cookies (or similar) to maintain a session between the RDAP client and RDAP server is acceptable. >>> I'm not saying that it is a wrong proposal but it would simply >>> result in refactoring the document. We should give answer to some >>> questions, such as: should the /tokens endpoint still be useful? >>> which information should the token response contain? how could >>> refreshment be requested ? >> >> Without having thought about this in detail: >> >> - The /tokens endpoint would no longer be useful, and would be >> removed. >> - Assuming that the RDAP server is able to use cookies to maintain >> session state with relevant RDAP clients, then the RDAP server >> could handle token refresh transparently. In the event that the >> token was expired and could not be refreshed, the RDAP server would >> prompt the user to authenticate again. > > [ML] Personally, I wouldn't object to your proposal. > > ... > > Anyway, if there was a consensus on reviewing radically the document to be > more compliant with the OIDC reference pattern, I would be pleased. Does anybody else have any input on this? -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
