Re: [regext] id_token parameter usage in rdap-openid
> -Original Message- > From: Tom Harrison > Sent: Wednesday, January 19, 2022 9:09 PM > To: Hollenbeck, Scott > Cc: mario.loffr...@iit.cnr.it; regext@ietf.org > Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in rdap- > openid [SAH] [snip] > > [SAH] I wonder if the changes made in -09 are helpful or not in the > > context of this discussion. It's worth re-reading the draft to be > > sure. > > It looks like the key update is that the ID token is no longer passed to the > RDAP server by the RDAP client, with the user's identifier taking the place > of > that token. However, if the RDAP server has only an access token and a user > identifier, it won't be able to determine definitively the authorisation > server > that it needs to contact to verify that token (I don't think the user's > identifier > is sufficient for a 1:1 mapping to an authorisation server in this respect). > Possibly another option is to pass back the 'iss' claim from the ID token to > the > RDAP client, and have the RDAP client provide that claim on each request. [SAH] According to the OpenID Connect Discovery protocol, it *is* possible to determine the OpenID Provider based on the identifier alone and out-of-band means. See: https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery So, I think we have that covered. > > Anyway, after thinking about it a bit I don't think we have an issue > > with sessions. I'm working with the following assumptions: > > > > 1. Every RDAP query is a discrete transaction between an RDAP client > > and an RDAP server. > > 2. Every access token has a validity period. > > 3. Every RDAP request that requires federated > > authentication/authorization includes an access token. > > 4. Access tokens can be refreshed when they get close to the end of > > their validity period. > > 5. An RDAP query that doesn't include an HTTP Authorization header > > should be treated as a request that does not require > > authentication/authorization. > > > > I don't see the need for additional session management features if > > these assumptions are valid. A "session" is tied to the validity > > period of the access token. The client requests tokens from the RDAP > > server (using a /tokens query) and is authenticated as a result of > > making that request. If the client can be authenticated, they receive > > a set of tokens that can be used for subsequent queries. The client > > provides the access token with each query that requires > > authentication/authorization. The client refreshes the access token > > (sending the refresh token to the RDAP serve using a /tokens query and > > a query parameter) as needed, and there's no need for the server to > > maintain additional state information. > > > > Am I missing something? > > The above is fine (IMHO, as somebody without any particular experience in > OAuth/OIDC/security) save for the need to map the request to a given > authorisation server. If returning the 'iss' claim to the RDAP client and > having > the RDAP client include that on subsequent requests solves that problem, > while also addressing the concerns around the use of the ID token, then > maybe that's the only extra thing that needs to happen. (My suggestion > about cookies was mostly about trying to head off the possibility of the > RDAP > server inspecting the access token > directly.) [SAH] Understood! Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] id_token parameter usage in rdap-openid
Hi Scott and Tom, Il 20/01/2022 03:08, Tom Harrison ha scritto: On Wed, Jan 19, 2022 at 01:22:04PM +, Scott Hollenbeck wrote: 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? [SAH] I wonder if the changes made in -09 are helpful or not in the context of this discussion. It's worth re-reading the draft to be sure. It looks like the key update is that the ID token is no longer passed to the RDAP server by the RDAP client, with the user's identifier taking the place of that token. However, if the RDAP server has only an access token and a user identifier, it won't be able to determine definitively the authorisation server that it needs to contact to verify that token (I don't think the user's identifier is sufficient for a 1:1 mapping to an authorisation server in this respect). Possibly another option is to pass back the 'iss' claim from the ID token to the RDAP client, and have the RDAP client provide that claim on each request. [ML] To Tom: Sorry but I didn't catch how the user identifier is sufficient to determine the Authorization Server in order to obtain the access token but then is no more sufficient when the same access token needs to be validated. The 'iss' claim (passed as a parameter instead of the "id" parameter once the access token has been obtained) can be helpful to save the RDAP server to run the discovery process at every request, However, the issuer is included in the ID Token so, unless such information was included in the /tokens response, it should be obtained by decrypting the ID token. Anyway, after thinking about it a bit I don't think we have an issue with sessions. I'm working with the following assumptions: 1. Every RDAP query is a discrete transaction between an RDAP client and an RDAP server. 2. Every access token has a validity period. 3. Every RDAP request that requires federated authentication/authorization includes an access token. 4. Access tokens can be refreshed when they get close to the end of their validity period. 5. An RDAP query that doesn't include an HTTP Authorization header should be treated as a request that does not require authentication/authorization. I don't see the need for additional session management features if these assumptions are valid. A "session" is tied to the validity period of the access token. The client requests tokens from the RDAP server (using a /tokens query) and is authenticated as a result of making that request. If the client can be authenticated, they receive a set of tokens that can be used for subsequent queries. The client provides the access token with each query that requires authentication/authorization. The client refreshes the access token (sending the refresh token to the RDAP serve using a /tokens query and a query parameter) as needed, and there's no need for the server to maintain additional state information. Am I missing something? [ML] To Scott: I mentioned the session managment because I have a little feeling that the OIDC pattern described in the draft may result in a inefficiency if the OP implements session management but, honestly, cannot estimate its extent. Session management is an optional OIDC feature. In addition, I'm only experienced with a local OP, specifically Keycloak, implementing the session management and I don't know how many OPs operate in the same manner. Just to summarize the matter, in OIDC session managment, once the end-user has been authenticated, a session (in place of an access token) is exchanged between the web browser and the RP. As a consequence, in order to comply with the draft spec, the RDAP server (acting as an RP in the draft) would be required to invalidate the session at every response and regenerate the security context starting from the access token at every request. I just presented my experience so if you think the draft shouldn't address this topic, I'm OK. Best, Mario The above is fine (IMHO, as somebody without any particular experience in OAuth/OIDC/security) save for the need to map the request
Re: [regext] id_token parameter usage in rdap-openid
On Thu, Jan 20, 2022 at 02:41:06PM +, Scott Hollenbeck wrote: >> -Original Message- >> From: Tom Harrison >> Sent: Wednesday, January 19, 2022 9:09 PM >> To: Hollenbeck, Scott >> Cc: mario.loffr...@iit.cnr.it; regext@ietf.org >> Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in rdap- >> openid > > [SAH] [snip] > >>> [SAH] I wonder if the changes made in -09 are helpful or not in the >>> context of this discussion. It's worth re-reading the draft to be >>> sure. >> >> It looks like the key update is that the ID token is no longer >> passed to the RDAP server by the RDAP client, with the user's >> identifier taking the place of that token. However, if the RDAP >> server has only an access token and a user identifier, it won't be >> able to determine definitively the authorisation server that it >> needs to contact to verify that token (I don't think the user's >> identifier is sufficient for a 1:1 mapping to an authorisation >> server in this respect). Possibly another option is to pass back >> the 'iss' claim from the ID token to the RDAP client, and have the >> RDAP client provide that claim on each request. > > [SAH] According to the OpenID Connect Discovery protocol, it *is* > possible to determine the OpenID Provider based on the identifier > alone and out-of-band means. See: > > https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery > > So, I think we have that covered. But it's not guaranteed that every user identifier will be associated with a host that is implementing issuer discovery. For example, an RDAP server might be configured to use multiple authorisation servers, each of which permits the use of arbitrary email addresses as identifiers. Because each permits arbitrary email addresses, it's not possible to use a simple mapping from the domain of the email address to the authorisation server. The RDAP server is then reliant on issuer discovery being implemented by the email host, but there's no guarantee that it will be (Gmail doesn't implement it, for example). If an RDAP server has some specific out-of-band means for mapping identifiers to authorisation servers, then it could rely on that, but that may not be possible in all situations. The RDAP server then has to fall back to requesting that the user select an authorisation server during the login process: this is fine, but it means that the RDAP server is receiving extra information during the login process that it won't have available to it during subsequent token-based requests. -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
