[IPP] Documenting IPP uses of HTTP authentication mechanisms (Basic / Digest / OAuth2)

[IPP] Documenting IPP uses of HTTP authentication mechanisms (Basic / Digest / OAuth2)

Michael Sweet msweet at apple.com
Fri Apr 21 12:06:26 UTC 2017


Smith,

> On Apr 20, 2017, at 11:48 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> ...
> If I am understanding what I'm observing correctly, when a browser receives an HTTP 401 with WWW-Authenticate, it will generally show some type of authentication dialog, corresponding to the authentication type (e.g. Basic and Digest may trigger presentation of a dialog with username and password text fields; certificate may present a certificate selection list).

Correct; the actual UI varies widely which is one of the reasons why most web sites do not use HTTP authentication...

> I have next to no experience with OAuth2, so I need some help with this. But looking at sequence diagrams that I cribbed for my own diagrams,   OAuth2 appears to have built into it an assumption that the client will allow presentation of HTML / web content in an HTML rendering window control. 

Not exactly.  There are a few required interfaces that need to be implemented by an OAuth2 server, one of which is a required GET endpoint that accepts a set of standard query parameters (what would be provided in a form) that can be used by a non-browser client ("native application" in their terminology) to enable the kinds of behavior we'd want/need for a printing client.  And this (non-idempotent...) GET request can be additionally authenticated using HTTP Basic to authenticate the client (...).

The bigger issue is that OAuth as a HTTP authentication scheme is poorly defined; the Bearer scheme (RFC 6750) does not include any parameters in the WWW-Authenticate header to point clients to the OAuth server to use, which is why we have a separate IPP attribute (accessible via Get-Printer-Attributes...) to tell the client which server endpoint to use...  The common usage for *that* method can be see in things like Github, where you get a multi-use access token from the Github web site and then use that as proof you are who you say you are...

TL;DR: OAuth is required to work without browsers.  And we have defined what is needed to implement IPP printers and clients that use it.  But actual implementation could probably use some documentation since there is obviously some confusion...

> ...
> Is OAuth2 used in managed print systems for authentication today?

I'm not aware of any large-scale deployments, but it is certainly possible there are proprietary systems doing so.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer



More information about the ipp mailing list