Re: IPP OAuth 2.0 question / potential gap: How should the Client manage multiple access tokens or realm identities?

Michael Sweet via ipp <[email protected]> Wed, 19 Oct 2022 09:29:57 -0400

Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>

Piotr,

> On Oct 17, 2022, at 5:49 PM, Piotr Pawliczek <[email protected]> wrote:
> 
> Hi Michael and Smith,
> 
> Regarding the implementation of the client, I would keep two caches:
> 1. access tokens for printers indexed by "printer-uri" (or for IPP Systems indexed by "server-uri")

I guess I figured we'd want to "pin" the OAuth server URI and scope with the printer/system ("resource") URI...

> 2. access tokens for Authorization Servers indexed by "oauth-authorization-server-uri" and "oauth-scope"
> 
> When the client communicates with a printer the cache 1 is used (when the printer requires OAuth). If the printer is missing there or the current access token is rejected the client queries  "oauth-authorization-server-uri" and "oauth-scope" from the printer and tries to match an entry in the cache 2. If the entry is found the client does TokenExchange (in the background) to get the new access token for the printer (and saves the new access token in the cache 1). If there is no matching entry in the cache 2, the client must go through the authorization procedure to get an access token for the authorization server and given scope ("oauth-authorization-server-uri" and "oauth-scope"). The authorization procedure here means standard Authorization Code flow with PKCE (opening the internet browser, letting the user to authenticate etc).
> Both these caches are kept in the context of the current OS user session (they are wiped out when the user closes the session).

I think we need to support persistence beyond the current session, at least for "system" accounts and other background processes that might need access even after the user has logged out (accounting, monitoring, general printing, etc.)  But for normal user sessions I agree the cached tokens can go away.

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp

signature.asc (application/pgp-signature, 833 B)