How to get User ID of someone authenticated via OAuth?

API Q&A
#1

Basically just what the topic says.

When authenticated via OAuth, I can do absolutely anything I need to-- I can make queries and changes all day, and I ASSUME that if I tried to do something I wasn’t allowed to, the app would properly forbid that though I haven’t tested it (it would be pretty pathetic if it didn’t).

The only (major) problem is I have no idea how to get any information about the user making the requests. It returns the auth key. The auth key lets them make requests. But other than that it’s anonymous.

The point of me trying to use OAuth is so that I can make a management side-car app that runs alongside bog-standard infusionsoft, allowing our lead people to automate repetitive tasks (such as ones that access external APIs) with a single click. But I need to be able to log the changes they make for auditing and to ensure that they’re able to take ownership of objects if they have a need to. I can’t make that work if I can’t tell who they are.

I understand that infusionsoft IDs are agnostic with regard to the app they’re used on, so it makes sense that the actual UserID is not returned by default (though it looks like if I could get the GlobalUserId of the OAuth’d user I could resolve that conundrum).

I’m using node.js with the passport and passport-infusionsoft packages.

Thanks in advance.

1 Like
#2

There is an undocumented call on the XML/RPC api to get the information. DataService.getUserInfo() we haven’t made the REST version yet though. The call will return the globalUserId, localUserId, appAlias, appUrl, displayName, casUsername. Since it is undocumented I would caution using it, but it is there.

#3

I’m really trying to stick to the rules you’ve so helpfully taken up half of my screen real-estate with, and criticize ideas and not people, but how has this not been an issue you’ve needed to solve yet? This would have absolutely been one of the first, if not THE first, fundamental functions I rolled into any OAuth API I wrote, all documented and finalized, tied up neatly-- “THIS is how you do it!”

One of the biggest selling points of OAuth, at least for anyone with experience on the Facebook or Twitter APIs, is to let someone else handle user accounts for you, one less thing to manage, or to centralize things so you only have to manage one set of accounts for everything.

Other than simple one-shot apps, like processing contact data in some way or things that are literally just scripts floating out on the internet somewhere (in which case why do you even need OAuth? Why not use the API keys?), I can’t really imagine the cases where user info isn’t necessary-- at least for maintaining your own logging, if nothing else. “We got hacked: whose account was compromised?”

You really need to get on this stuff. Developers can be your best friends, writing “killer apps” that net huge benefits to your platform, or they can warn people away from ever touching you. I’m trying not to be arrogant or browbeat you, I’m sure you people have your own burdens, but if you think this is even on par you need to wake up. This kind of thing severely hobbles you.

#4

@Chuck_Reed I understand your frustration. There are very good reasons why this hasn’t been added to the REST API yet. We have been prioritizing our REST api work based on moving people off of the existing XML/RPC API. This means we have been tackling endpoints based on call volume against the XML/RPC API. We are doing weekly releases so new endpoints are being added all the time. Historically getting the current user information has rarely been a requested feature.

The concept of a user context is foreign the the legacy XML/RPC API. The DataService.getUserInfo() method was put together quickly and wasn’t put through the the full process to be released as a documented call, but we have told people about it when asked if something like this exists.

When we started work on the REST API we wanted user context to be a first class citizen in the API. Which we have done, with the exception of providing an endpoint to expose it via an API call. This as you have pointed out is a shortcoming. Our OAuth implementation was not initially intended to be an Identity Provider solution similar to what you can accomplish with Facebook. That doesn’t mean it shouldn’t be. We have looked into some of the newer specs around Identity Management like OpenID Connect. This is probably the route we will take. It is on our radar from an REST API perspective and an Identity Provider perspective.

Yesterday after responding to your question we added the current user endpoint to our backlog to be worked on. We will prioritize it against our existing work. We do our best to respond to our developers needs and I am sure this endpoint will be completed sooner rather than later. Please keep in mind our team has limited resources just like everybody else. We are doing our best to provide our developers with the best experience possible and we need good feedback like this from our developers to help us prioritize and deliver the features you guys want/need.

#5

Thanks.

I managed to get it all working, even had to write a pull request for node-xmlrpc to get there (apparently it’s very rare for people to use an http query string in xmlrpc requests, even though the spec seems to explicitly allow it).

But this morning when I went to test it, I keep getting this error message back from the server whenever I try to call the DataService.getUserInfo method:
XML-RPC fault: [InvalidParameter]Unable to obtain global user ID from request for: (my sandbox app name)

I even tried resetting back to the commit when I very first had it working, same error. Any idea what’s up?

#6

Hi @Chuck_Reed, we were having an issue with our API proxy provider Mashery this morning but it has since been resolved. Can you try again and let us know if you’re still seeing any issues?

#7

Works great, thanks!

#8

Hi Bradley,

We are in a similar situation as Chuck was. I was wondering what it is the current situation of the current user endpoint and if there is target date for it.

Many thanks in advance,
Luis

#9

This was actually just released a couple days ago, but the docs are not up to date yet. The endpoint is /oauth/connect/userinfo It will return an OpenId Connect 1.0 compliant response that looks like

{
    "sub": "1",
    "email": "email@domain.com",
    "given_name": "Bradley",
    "family_name": "Booth",
    "middle_name": null,
    "global_user_id": 54,
    "infusionsoft_id": "email@domain.com",
    "preferred_name": null
}

sub is the local id of the user in the app. We will get the docs pushed up soon.

1 Like
API Additions and Changes 2018-01-09
#10

Awesome! We are already using it!

Many thanks,
Luis

1 Like
#12

The docs are live, now: Retrieve User Info.

1 Like