oauth2orize icon indicating copy to clipboard operation
oauth2orize copied to clipboard

Support for Installed Applications Flow

Open kimar opened this issue 11 years ago • 5 comments

I didn't find any information about support for installed applications which use redirect_uri=urn:ietf:wg:oauth:2.0:oob. This currently leads to a redirectal error, which is perfectly correct, but shall lead to a page containing the access_token inside the html body response.

Thanks for your support.

kimar avatar Dec 26 '13 12:12 kimar

+1

I want to know informations about Installed Applications Flow with oauth2orize.

Any tip, @jaredhanson ?

fjorgemota avatar Feb 09 '14 21:02 fjorgemota

Here's how I worked around this. In the client authorization step check for a redirectUri of urn:ietf:wg:oauth:2.0:oob and set the redirectUri parameter passed to the done callback to be a local route that is a simple view with the code in the title.

// Authorize the client id and redirect URI
var authorizeClient = oserver.authorize(function(clientId, redirectUri, done) {
  Client.findById(clientId, function(err, client) {
    if(err) return done(err);

    // Verify that we got a client from the DB
    if(!client) return done(null, false);

    // Verify the requested redirect Uri is valid
    if(redirectUri !== client.redirectUri) {
      var u = require('url');
      var url = u.parse(redirectUri);
      var curl = u.parse(client.redirectUri);

      // For localhost Uris, match everything but the port
      if(curl.hostname !== 'localhost' ||
        (curl.hostname !== url.hostname || curl.protocol !== url.protocol)) {
          return done(null, false);
      } 
    }

    // For the out-of-band flow
    // redirect to a local route to display the code in the page title
    if(redirectUri === 'urn:ietf:wg:oauth:2.0:oob')
      redirectUri = '/oauth2/oob';

    return done(null, client, redirectUri);
  });
});

joshperry avatar Aug 20 '14 17:08 joshperry

What a concidence I'm digging up this old one from its grave exactly two years after you've answered it 😄

I've implemented the solution and you've described and it works quite well, btw is there any common understanding of how to propagate the access_token to the user? I've seen a few ways (e.g. yours using the title, others doing it via JS). I'm currently presenting an "Authenticating…" page to the user and then the app has to decide how to retrieve the token. I've implemented multiple ways.

kimar avatar Aug 21 '16 07:08 kimar

@kimar This is actually something I yanked from Google, it's not described in the rfc. In fact, it looks like Google is even poo-pooing this method now and recommending it not be used unless necessary (it's hidden beneath an exposer now, "Alternative Redirect Choices"): https://developers.google.com/identity/protocols/OAuth2InstalledApp#choosingredirecturi

I'd definitely prefer to use the custom URI schemes that all OSs provide for applications now for delivering the code. This is probably the direction we'll be heading, but I will probably keep this in our system for downlevel compatibility.

joshperry avatar Aug 21 '16 09:08 joshperry

I agree, that's definitely what we should be heading for. I've been using this flow for third party apps but I'm about to implement it for our own apps as well and I'm aiming for the custom URI schemes.

kimar avatar Aug 21 '16 10:08 kimar