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

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

Michael Sweet msweet at apple.com
Fri Nov 10 17:53:28 UTC 2017


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) <smith.kennedy at hp.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20171110/a7d17f08/attachment.html>


More information about the ipp mailing list