support for oob/urn:ietf:wg:oauth:2.0:oob redirect uris

[vegitron]

I have client applications that aren't able to run a web server, or get redirects to a custom protocol. These are unix command line tools, not phone apps or websites. I would need to have users copy/paste their access codes so the app can get the tokens.

I was able to hack this functionality into place, by allowing oob:// as a custom protocol. Then in my service provider I subclassed the AuthorizationView, to turn any redirects to an oob:// url into a redirect to a custom view in my service provider that shows the access code:

class OOBAuthorizationView(AuthorizationView):

def post(self, *args, **kwargs):                                            
    value = super(SSAuthorizationView, self).post(args, **kwargs)           

    location = value.get("Location", "")                                    
    if location and re.match("oob://", location):                           
        new_base = reverse("oauth_access_code")                             
        new_url = "%s?code=" % new_base                                     
        location = re.sub("^oob://.*\?code=", new_url, location)            
        value["Location"] = location                                        
    return value   

I would really like to be able to get rid of this hack.

[masci]

Hi @vegitron, do you mind to elaborate a bit on what is the workflow you're currently using, I'm not sure I understood what you need. TIA

[vegitron]

Sure. Part of my application is a command line tool, to let people either use my app as part of a script with other tools, or do things like uploading large datasets that they wouldn't want to do through their browser.

Considering the various authorization grant types:

Client credentials isn't appropriate, since this is manipulating user data, and definitely isn't trusted.
Password doesn't work for me, because my users are authenticating through 3rd party resources.
Implicit doesn't work because there's no browser to see the hash.
Authorization code does what I want - it forces user authentication, and application approval.

So what I'm doing is something like this:

./bin/my_app upload file.dat
You need to log in to continue.  After logging in, enter your access code below.
Log in at  https://myserver.com/o/?...

Access code:

The user logs in, approves the application access, and sees a page that gives them the code they need to enter. They enter it into the app, the app uses that to request the oauth access token and refresh token, and then does it's work. That access code is the same one that would have been given in the redirect uri.

Does that make my goal more clear? Thanks!

[kevin-brown]

I'm going to 👍 this.

Here's some information on how Google handles it.

[gcushen]

👍 This is an important part of the OAuth2 spec and is simple to implement (just a view to enable a user to copy the code). Without it, CLI code grant clients cannot function (unless workarounds are created). Ideally, both urn:ietf:wg:oauth:2.0:oob and urn:ietf:wg:oauth:2.0:oob:auto should be supported, as referenced by @kevin-brown.

[jleclanche]

PR wanted!

[georgedorn]

A lot can be gleaned from google's oauth2client library: https://github.com/googleapis/oauth2client

urn:ietf:wg:oauth:2.0:oob results in a human-friendly html page containing the token, possibly embedded in a branded template (i.e. extends base.html). A lot of applications, for legacy reasons, use this and regex to extract the token, risking summoning zalgo in the process.
urn:ietf:wg:oauth:2.0:oob:auto returns JSON, with details about the token. The access token is appropriately named access_token and other useful fields are described here: https://github.com/googleapis/oauth2client/blob/master/oauth2client/client.py#L618

A PR would need to include a simple template for the non-JSON version (probably including the access token in <code></code> tags to work with legacy clients, but the auto version should be easier.

[marnanel]

Can we close this now?