OOB OAuth?

[Scott Chamberlain]

Hi, 

With the rorcid R client I'm working on, I have OAuth supported now, but it doesn't work for OOB OAuth (e.g., when behind a firewall where the redirect URL I have localhost:1410 won't work).

Seems like the redirect_uri for OOB is "urn:ietf:wg:oauth:2.0%".

Is there anything that might be not working on your end that would prevent this from working?  I wonder if I need to do anything separate for when users need to do OOB OAuth?

Thanks, Scott

[Peters, Robert]

Hey,
Yes. We are not aware of it and will have to do some research. Do you have a good spec reference handy?

https://localhost:1410 should work for a local client on a local machine even behind a firewall.

Cheers,
Rob

Robert Peters

Technology Director at ORCID.org

Cellphone: +1.805.440.9056

Email: r.pe...@orcid.org

Skype: rcpeters

Timezone: PST
Key for OpenPGP email communication:  
https://keys.mailvelope.com/pks/lookup?op=get&search=0x1519F37D99E18378

--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-users+unsubscribe@googlegroups.com.
To post to this group, send email to orcid-api-users@googlegroups.com.
Visit this group at https://groups.google.com/group/orcid-api-users.
For more options, visit https://groups.google.com/d/optout.

[Scott Chamberlain]

Thanks, I don't see mention of it in the oauth spec. Maybe https://developers.google.com/api-client-library/python/auth/installed-app 

Best, Scott

On Friday, February 2, 2018 at 1:30:33 PM UTC-8, Robert Peters wrote:

Hey,
Yes. We are not aware of it and will have to do some research. Do you have a good spec reference handy?

https://localhost:1410 should work for a local client on a local machine even behind a firewall.

Cheers,
Rob

Robert Peters

Technology Director at ORCID.org

Cellphone: +1.805.440.9056

Email: r.pe...@orcid.org

Skype: rcpeters

Timezone: PST
Key for OpenPGP email communication:  
https://keys.mailvelope.com/pks/lookup?op=get&search=0x1519F37D99E18378

On Fri, Feb 2, 2018 at 12:26 PM, Scott Chamberlain <myrmec...@gmail.com> wrote:

Hi, 

With the rorcid R client I'm working on, I have OAuth supported now, but it doesn't work for OOB OAuth (e.g., when behind a firewall where the redirect URL I have localhost:1410 won't work).

Seems like the redirect_uri for OOB is "urn:ietf:wg:oauth:2.0%".

Is there anything that might be not working on your end that would prevent this from working?  I wonder if I need to do anything separate for when users need to do OOB OAuth?

Thanks, Scott

--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-use...@googlegroups.com.
To post to this group, send email to orcid-a...@googlegroups.com.

[Scott Chamberlain]

Hi Rob, Any update on this?

Best, Scott

[Peters, Robert]

Hi Scott,
I'll tag Tom to look into if this would be easy to support.

Thanks,
Rob

[Demeranville, Tom]

Hey Scott

The urn:ietf:wg:oauth:2.0 value looks like a standard, but it isn't.  It's a google invention that's been picked up by others.  From what I can tell it's put in place of a return_url and used in two ways:

1. After login, our authorization point displays a page with the authorization code as the window title.  Another app (like a phone app or desktop app) reads the code from the window title, closes the window, then does the backend exchange.

2. After login, our authorization point displays a page with the authorization code in a box with instructions to cut and paste it into another app.  Which then exchanges it as normal.

It is a useful thing.  We've been asked for the functionality of (2) by others, but I had no idea this 'standard' existing, so my advice so far has been for them to basically implement (2) on their own server.

Regarding the problem as reported (localhost return urls not working) I don't see this as a solution to that.  Unlike google, we support localhost return urls, so I'm not sure what the problem is.  Could you give more details?

Best,

Tom Demeranville

Technology Advocate

ORCID Inc

https://orcid.org/0000-0003-0902-4386

[Scott Chamberlain]

Thanks very much Tom. ORCID Oauth is working with a localhost return_url but as I pointed out in the opening comment in this thread it's not working when the user is behind a firewall. I've since lost the email or issue that brought this issue up, so I can't give more details.

What would be really nice is if ORCID would allow users to get a personal access token (PAT) and use that for auth instead of doing the OAuth dance. That would be SO SO much easier for programmatic use cases. AFAIK that's not allowed yet. Any chance it will be?

Best, Scott

[Demeranville, Tom]

Hi Scott,

The thing with PAT and ORCID is that only ORCID members can have update permissions.  This means that if we generated PATs for researchers, they'd only have the authenticate and read-public scopes. 

That said, the google oob authorisation code approach may well solve the same problem.  It generates a code that a researcher can give to a member integration, which in combination with their member cerdentials could be used to generate a token in programatic use cases.

Would that work in the cases you're considering?

Best,

Tom Demeranville

Technology Advocate

ORCID Inc

https://orcid.org/0000-0003-0902-4386

[Scott Chamberlain]

Hi Tom,

I'm confused on what you're getting at with the "oob authorisation code approach". What do you mean by a code that a researcher can give to a member integration?  Do you mean a web app?  Or could an integration be an app I've registered for that represents my R package rorcid?  What would the workflow look like to get one of these codes?  Would you still have to go through the browser?

Scott