Subject: Re: [IPP] Assistance in correcting the "OAuth2" diagram in IPP Authentication?

From: Michael Sweet <[email-masked]>
Date: Fri, 10 Nov 2017 12:53:28 -0500

Smith,

OK, so to "help" I think we need to separate things because OAuth2 has three distinct steps:

1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server.  The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df <myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df>"), which is how you implement OAuth2 for so-called "native apps".

2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the authorization server using a HTTP POST (no web browser needed).

3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.

Only step 1 requires a web browser.

Only step 3 is in-band of IPP.

The token you get in steps 1 and 2 can potentially be reused indefinitely.  When you get a 401 with and error parameter in the WWW-Authenticate header, it is time to either a) refresh the access token or b) repeat steps 1 and 2 to re-authenticate.

The list of RFCs is extensive (https://oauth.net/2/ <https://oauth.net/2/>) but the important ones for IPP are:

- RFC 6749: The OAuth 2.0 Authorization Framework (doing out-of-band authentication and getting access tokens)
- RFC 6750: OAuth 2.0 Bearer Token Usage (doing in-band authentication)
- RFC 7636: Proof Key for Code Exchange (doing out-of-band authentication more securely with native Client applications)
- RFC 8252: Recommendations for using OAuth 2.0 with native apps (doing out-of-band authentication on a Client - for implementors)

The following Internet Draft will (hopefully) define how an input constrained device like a printer can authenticate as a client (important for IPP INFRA proxies).

> On Oct 25, 2017, at 3:59 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Hi Mike,
> 
> One of my action items to move the IPP Authentication white paper forward was to solicit help from you in correcting the OAuth2 diagram(s). Could you take a look at the attached PlantUML sequence diagram files and make corrections you feel are needed? The versions from the latest white paper (from August) are attached - there are two of them. You can edit it in any text editor, then render it using the PlantUML tool:
> 
> http://plantuml.com/download
> 
> Thanks in advance! 
> 
> 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-authentication-6-http-oauth2.pu><ipp-authentication-8-http-oauth2-with-digest.pu>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

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

---

From: "Kennedy, Smith (Wireless & Standards Architec)" <[email-masked]>
Date: Wed, 15 Nov 2017 04:44:39 +0000

Hi Mike,

I'm not sure how to incorporate your feedback into the current OAuth2 sequence diagram. I will list some of my questions here, but we may need to save discussion till the F2F session.

> 1. Web-based authentication/authorization - a web browser has to be used, out-of-band from IPP, to obtain a "grant" from the Authorization Server.

Could that not be implemented such that the client provides its own "web view" able to render web content as per the current OAuth2 sequence diagram?

Also, if IPP is performed before Step 1, then is the "Step 0" a IPP Get-Printer-Attributes or Validate-Job IPP operation?

>  The grant is supplied via a URL redirect that is primarily geared towards web services (point to a HTTPS web page on service X) but can also use application-specific URL schemes ("myspecialapp://bla/?code=fsdlfkjasdfdsfsd0324df"), which is how you implement OAuth2 for so-called "native apps".

OK so the HTTP response will be an HTTP 302 or similar, where the URL could be an https scheme, or could be some other scheme? What about the "ipp" scheme? Or maybe that is too premature / inappro. But the token comes in as basically a parameter in the URL in the 30x redirect response?

> 2. Once you have the grant, you can request an "access token" (and optionally a "refresh token", which is essentially a grant you can use at a later time to keep using the resource) from the author…

So the "grant" is basically an "access token access token" that allows the Client to request an "access token"?

> 3. Once you have the access token, you can supply it in response to the HTTP 401 status code with a "WWW-Authenticate: Bearer" header.

And it is up to the Client to manage that access token? Is it typically stored in a cookie or via some other place / method?

Smith

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

> On Nov 10, 2017, at 10:53 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Oct 25, 2017, at 3:59 PM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Mike,
>> 
>> http://plantuml.com/download <http://plantuml.com/download>
>> 
>> Thanks in advance! 
>> 
>> Smith
>> 
>> /**
>>    Smith Kennedy

---

From: Michael Sweet <[email-masked]>
Date: Wed, 15 Nov 2017 06:24:55 -0500

Smith,

> On Nov 14, 2017, at 11:44 PM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked]> wrote:
> 
> Hi Mike,
> 

Technically yes, however the current best practice is to run the authentication page either in the default web browser or an isolated web view so that the application does not have access to state/cookies/etc. that it shouldn't have access to and it isn't as easy to spoof the OAuth authorization form.

> Also, if IPP is performed before Step 1, then is the "Step 0" a IPP Get-Printer-Attributes or Validate-Job IPP operation?

You need to do a Get-Printer-Attributes request to get the OAuth Authorization Server URL ("oauth-authorization-server-uri") to use in step 1...  You might have done other IPP requests the triggered the 401 response with the Bearer scheme challenge, or you might have gotten the authentication info when presenting the print UI and then proactively done the authentication step.

> OK so the HTTP response will be an HTTP 302 or similar, where the URL could be an https scheme, or could be some other scheme? What about the "ipp" scheme? Or maybe that is too premature / inappro.…

Yes.

(and as for using "ipp" as the scheme, that is totally OK but just needs to be registered with the client ID when you setup the OAuth environment...)

> So the "grant" is basically an "access token access token" that allows the Client to request an "access token"?

Yeah, you could look at it that way.  The second step basically is a way of confirming that you did the first step and got the redirect - kind of like getting a credit card and then calling to activate it.

> And it is up to the Client to manage that access token? Is it typically stored in a cookie or via some other place / method?

The access token must be protected just like a password.  And that's why the "destination-accesses" and "document-access" collections are operation attributes - they are not externally visible in the Job object because they contain sensitive information that is not supposed to be exposed.