Subject: [IPP] OAuth in IPP and the "oauth-authorization-server-uri" IPP attribute

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 24 Jul 2017 18:37:21 +0000

Greetings,

I am working on converting the "IPP Authentication" slide set to a whitepaper. In the process, I've been considering OAuth a bit more. PWG 5100.18 (IPP Transaction Based Printer Extensions) defines the "oauth-authorization-server-uri", "access-oauth-token", and "access-oauth-uri" attributes. It isn't clear to me how these attributes integrate into an OAuth authentication system. 

The way that OAuth / OAuth2 seems to work, there will be an HTTP response redirecting the User Agent (IPP Client) to a different server for authentication. If this is all handled at the HTTP layer, what value do these IPP attributes provide?

Thanks for any help,

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

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

---

From: Michael Sweet <[email-masked]>
Date: Mon, 24 Jul 2017 16:33:15 -0400

Smith,

PWG 5100.18 is IPP INFRA... :)

The "oauth-authorization-server-uri" Printer Description attribute specifies the OAuth server that the printer uses (and thus the client must use to obtain a bearer token) - this is needed because RFC 6750's WWW-Authenticate header does not include the authorization server...

OAuth Bearer tokens (used for HTTP authentication) do NOT rely on redirection, but instead use a cached token string that the Client obtains by going to the auth server.  Think Github API tokens...

The "access-oauth-token" member attribute contains the bearer token for the specified remote resource, and is how you provide third-party access to a resource.  The "access-oauth-uri" points to the OAuth server used.  The Printer uses the "access-oauth-token" value in the HTTP Authentication field, e.g.:

    Authentication: Bearer dflkjfler232rsdlfkj45efdlk12fasf

> On Jul 24, 2017, at 2:37 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 25 Jul 2017 03:35:33 +0000

> On Jul 24, 2017, at 2:33 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

Eeek - how did I make that mistake?  :p 

>    Authentication: Bearer dflkjfler232rsdlfkj45efdlk12fasf

I'm clearly not an OAuth2 expert, but the diagram I have in my "IPP Authentication" deck, with an HTTP 302 Found redirection seems to be describing a different use of OAuth2 authentication than what is outlined in RFC 6750 - is that a fair statement? IPP INFRA didn't mention RFC 6750 so the distinction is not clear. And are you saying that an OAuth2 "Access Token" is NOT a supported authentication mechanism for IPP? (Am I reading this right?) Is this because you are trying to control access on a per-resource basis?

Do we need additional keywords for "uri-authentication-supported" to make it clear that 'oauth' refers to OAuth2 Bearer authentication [RFC6750]? (What about kerberos?)

---

From: Michael Sweet <[email-masked]>
Date: Tue, 25 Jul 2017 12:26:20 -0400

Smith,

> On Jul 24, 2017, at 11:35 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
>> ...
> I'm clearly not an OAuth2 expert, but the diagram I have in my "IPP Authentication" deck, with an HTTP 302 Found redirection seems to be describing a different use of OAuth2 authentication than what is outlined in RFC 6750 - is that a fair statement?

Not exactly.

OAuth is a multi-headed beast.  RFC 6749 defines the core framework, which standardizes how you get an access token using HTTP requests.  RFC 6750 defines the HTTP authentication scheme (Bearer) which allows individual HTTP requests to be authenticated using the token obtained via the mechanism defined in RFC 6749.  It is all the same protocol, but one (RFC 6749) does the authentication and authorization while the other (RFC 6750) transfers the record of that authentication and authorization (the token) for a given HTTP request.  And unlike Kerberos, that token can be reused and provided to third parties as long as it is valid.

> IPP INFRA didn't mention RFC 6750 so the distinction is not clear. And are you saying that an OAuth2 "Access Token" is NOT a supported authentication mechanism for IPP? (Am I reading this right?) Is this because you are trying to control access on a per-resource basis?

No, what I am saying is that the token you get from RFC 6749 gives you access to the Printer.  That access MAY restrict what you can do, e.g. normal user vs. operator or admin user, based on the authenticated user's role(s).

> Do we need additional keywords for "uri-authentication-supported" to make it clear that 'oauth' refers to OAuth2 Bearer authentication [RFC6750]?

No, but we should make it clear (in a future errata or white paper) that 'oauth' includes the RFC 6750 Bearer authentication scheme for HTTP - the two RFCs are a set because IPP uses HTTP as its transport.

> (What about kerberos?)

Kerberos uses the Negotiate authentication scheme to pass the token to the printer, and gets a similar WWW-Authenticate header in the 401 challenge.  Also like OAuth, authentication and authorization (to generate the token) happens separately.  But unlike OAuth all of the Kerberos tokens are single use.