You are the user (consumer, client).

Look at the curl example on your provider's site. It's about as basic as one can get. The constructor for LWP::Authen::OAuth2 requires the information that is needed for the request_token call, which is how you actually authenticate the client (instance of LWP::Authen::OAuth2). The instance (client) will then utilize the token when making calls via get, post, etc.

Most of the complication is actually on the provider's end in facilitating the "conversation" that generates the token and sets access controls; but this is all done on the provider's end. LWP::Authen::OAuth2 is for the one making the API calls (you).

Update - not sure, but looks like there are some service specific provider modules, e.g., LWP::Authen::OAuth2::ServiceProvider::Dwolla. So I am not sure if it's ready to roll out of the box or it just provides a foundation for something whacky a provider might do. Good luck.

You were right @perlfan. It was easy, and I was able to do it using LWP::UserAgent rather than implementsing LWP::Authen::OAuth2. I only thought I had to do the later because they recommended using a standard library for the OAUTH transactions so I thought it was more complicated. I stand by my rants about OAUTH2 tho :-)

But wait, user is not the same as consumer according to that primer. That is what's so confusing about this. OAuth2 seems to be designed for the case where I write an app that someone else will use to access a provider's data. I just want to get data from the API myself, so I guess that collapses I and someone else. But then I have to somehow authorize myself to get the data, as if I were not me? If perlmonks had emojis, I would totally insert that exploding head one right here.

Have you even tried the curl command to get the auth token from them? It seems like if you signed up, got a "secret", and made that call you'd be 90% there. Are you on Windows or something and don't have a decent commandline?

Egad. It takes an HOUR LONG VIDEO to properly explain OAuth2?

You could also just try to reproduce the initial curl command in the docs. That's about as clear as you'll get. Once it becomes a tangible experience, I think much of your confusion will go away.

• The service provider is the provider of the service which must be accessed.
• Your software is the direct consumer of those services, tasked with doing the right thing at the right time.
• You act on behalf of the user, who is probably a human being who may or may not be legit.