How do you write an OAuth2 server in Perl?

Question

I'm trying to wrap my head around OAuth2 and Perl (i.e. Net::OAuth2) – specifically, setting up a RESTful API for a database, and an application that uses it.

Perl Oauth2 package led me to Net::OAuth2.

As near as I can figure, there are a couple of things I need to do (please correct me if I'm off in the weeds somewhere):

1. Server-side: build the REST server (currently playing with mojolicious for this), which talks to the database.
2. Server-side: build the authentication/authorization server (??)
3. Client application: uses WWW::Mechanize (or some such) to talk to the REST server

In my head, here's how it works:

1. the client app has an API key (registered with the server (REST server? Auth server?), and “baked in” to the client)
2. the user has an entry (username and password) in a table in the database on the server
3. the user fires up the client app, and tries to access a protected resource (say to update a row) (again, for example, by selecting a “do this thing” menu option in the client; the client translates that into the REST API URI, eg http://the.rest.server/api/thisthing)
4. the server redirects the client to (the server's) authentication / authorization bit
5. the server, client, and user do a magic OAuth dance to authenticate the user
6. the server, client, and user do another magic OAuth dance to make sure the user is authorized to see that resource URI
7. if everything is good, the server re-redirects the client to the originally-requested resource URI (with whatever auth parms are needed).

Is that a reasonable assessment of the process?

If so, would it make more sense to have the “authentication/authorization” as part of the REST server, or as a completely separate server? (on the same hardware).

Net::OAuth2::Profile::WebServer nicely explains what has to happen on the client application side.

The tests in http://cpansearch.perl.org/src/MARKOV/Net-OAuth2-0.55/t/ (unless I'm really missing something) are about working with Net::OAuth2 webserver profile, which would (again) be the “client application”.

There are other examples for writing the client – connecting to an existing OAuth2 server, such as the Google API stuff – but I can't find examples of writing the server.... (I'm quite willing to RTFM, if I can find the FM... pointers appreciated!)

Answer 1

The general idea is to let a central auth server to handle the credentials + token generation + policy handling (policy => is this app authorized by this user).

Let's talk of the OAuth server first.
i) The server is responsible for a login page where the user can key in his credentials.
ii) Validates the credentials, if correct this server then checks which client app made the call and verifies whether "is this app authorized by this user". - Here comes in the concept of scopes.
iii) Generates an access token/authorization code for the app.
iv) When an API is hit by a client with an access token, the API should internally pass the token to this server. It's this server's job to verify the token contents.

Now, the APIs
i) The API should accept token from a client app, pass it to the server - fetch a unique customer ID from the server and return data to the client for that customer.

For the 3rd party apps,
i) You need to have a registration process. The client's need to have client-id and secret. Google allows you to register in the console.
ii) There should be a scope that maps to each unique API. Eg, when you make a Google OAuth app, you need to register your app for a scope - scope being G+, picasa, google drive etc.
iii) Access token are unique to scope and map to the permissions granted to your app by the user. If the user client app selects only G+ scope, and is granted access by the user - the app can use the token only for the G+ endpoint.

A more detailed answer on how to implement an OAuth server can be found here : How would an efficient OAuth2.0 server / provider work?