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

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

Michael Sweet msweet at msweet.org
Thu Oct 20 14:19:40 UTC 2022


Smith,

> On Oct 19, 2022, at 6:25 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>>> ...
>>> 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...
> 
> I think I agree with this but the primary "key" would be the printer-uri, and the value / record would need to include the "device" access token acquired earlier following token exchange.

My point is just that you need to verify that the OAuth server and scope haven't changed from when you got the access token for a given printer.

>>> 2. access tokens for Authorization Servers indexed by "oauth-authorization-server-uri" and "oauth-scope"
> 
> This sounds a bit awkward but I agree with this in principle. 
> 
> However, I want to come back to an ambiguity that I still think we need to work out. I've attached a use case diagram from the PDF I posted to the wiki page.
> 
> As we have already established, a mobile Client such as a laptop or smartphone may discover and interact with multiple printers, and those printers may be in different "contexts" or "domains" (e.g. at "work" and at "home"). It is possible that all the printers the Client encounters may not list unique hostnames for "oauth-authorization-server-uri" on a per-context or per-domain basis; both the "work" and "home" contexts may both be served by "authz.x.io".
> 
> That means that the Client is unable to distinguish the different contexts using the hostname.
> If in step 3, the Client doesn't provide an identifier for that printer (e.g. certificate or "printer-uuid" or something else unique to that printer), "authz.x.io" won't know whether the credentials provided in step 3 are legitimate for the "context" that the printer belongs to. Waiting until step 6 and potentially returning another HTTP 401 in step 7, would be a bad user experience, wouldn't it?

OK, let's use a concrete example:

1. You are using Google Identity for authorization
2. You have a home account ("mike at gmail.com") and a work account ("mike at work.com") setup with Google.
3. Your home and work printers point to "https://accounts.google.com/o/oauth2/v2/auth". The scopes can be anything (and are probably different).

> So what value should the Client be providing in step 20 of the big sequence diagram (ipp-authentication-6-http-oauth2.pdf) so that the printer / context can be conveyed? Did we ever come to consensus on that?

Aside from the scope, there is nothing that the Client can convey to specify context to the OAuth authorization server.  Yes, this is a usability issue when home and work use the same OAuth provider, but I don't think there is anything we can do about it. :/

________________________
Michael Sweet



More information about the ipp mailing list