OAuth2 Tutorial using Google as Authentication Service
Membrane Service Proxy can be used to authorize HTTP requests based on the RFC 6749 OAuth 2.0 Authorization Framework.
To use the exact terms, Membrane Service Proxy can act as a authorization proxy to the resource server. (Skip ahead to the description of the workflow to check out the architecture overview graphic.)
This tutorial consists of two sections:
- Setup Google as Authorization Server
- Perform a sample OAuth2 request authorization.
This tutorial takes about 10 minutes to complete. A Google account, internet connection and Membrane Service Proxy 4.0.7 or higher is required.
1. Setup Google as Authorization Server
Step 1: Open the Google API console
Go to https://code.google.com/apis/console/ and login to your Google account, if necessary.
Click on Create project...
Step 2: Creating an OAuth 2.0 Client ID
Click on API access in the menu on the left.
Click on Create OAuth 2.0 client ID...
Choose a product name, for example My Secret Resource.
The product name will be shown to users together with the question "Do you want to share your email address and identifying information with this app?"
It should inspire trust for the user to answer "Yes".
Enter the Membrane's public URL as the Home Page URL.
The public URL is the URL your users will be using to access Membrane (or, to be more specific, the secret resource via Membrane). In our case, we used http://localhost:8080/. For production use, one might use a publicly registered domain name. This means that only users accessing Membrane from the same host as Membrane is running on will be able to seamlessly login. (Note that other users might still be able to login via manual URL manipulation.)
Choose Web application as the application type and once more enter Membrane's public URL. Choose HTTP as protocol.
Click on Create client ID.
Leave this browser tab open, as we later need the first part of the Client ID (without .apps.googleusercontent.com) and the Client secret for Membrane's configuration.
Step 3: Configure Membrane Service Proxy
Download the Membrane Service Proxy distribution version 4.0.7 or above.
Extract the .zip archive and go to the /examples/authorization/oauth2 directory.
Open Membrane's configuration file, proxies.xml, for editing.
The <router>...</router> element has got following configuration:
<serviceProxy port="8080"> <headerFilter> <exclude>X-Authenticated-Email</exclude> </headerFilter> <oauth2Resource loginLocation="dialog" publicURL="http://localhost:8080/"> <google clientId="826870501040" clientSecret="PdtH9leMnwh2Y3IH4jQOqgcQ" /> </oauth2Resource> <groovy> def email = exc.request.header.getFirstValue("X-Authenticated-Email") exc.response = Response.ok("Hello " + email + ".").build() RETURN </groovy> <!-- Use the <target> instead of the <groovy> interceptor to forward requests to another host: <target host="membrane-soa.org" port="80" /> --> </serviceProxy>
Replace the clientId and clientSecret by the ones from your Google API Project.
Step 4: Start Membrane Service Proxy
Go back to your file explorer to the /examples/authorization/oauth2 directory of Membrane.
Start Membrane by double clicking service-proxy.bat.
The console shows Membrane's log messages.
As configured, Membrane is now listening on port 8080 for incoming HTTP connections. In the next section, we will connect to it using a browser and follow the OAuth2 steps to access our simulated "secret resource".
2. Perform a sample OAuth2 request authorization
As the full OAuth2 workflow is quite complex, we only describe a relevant subset in this tutorial.
Step 5: Try to access the "secret resource"
Keep Membrane running (the console open).
Open a browser and go to http://localhost:8080/.
Click on here.
Click on Accept to allow Membrane to retrieve your email address.
Congratulations, you have successfully completed an OAuth2 authorization setup.
Enjoy the simulated "secret resource", a personalized "hello" message from Membrane. ;)
In our setup, we used a simple, dynamically generated "Hello <your-gmail-address>." page as the secret resource. The secret resource does not have to be hosted within Membrane, but can reside on any other HTTP server Membrane has access to, including localhost.
- We did not perform any further checking of the user’s email address to protect our secret resource. In practice, you should do that, as getting possession of a valid gmail login is not really a challenge. ;)
- The web server hosting the secret resource should probably be protected by a firewall so that the user cannot access the secret resource directly by circumventing Membrane.
You should use HTTPS for all untrusted network connections. Membrane’s administrator should install SSL certificates and adjust the proxies.xml to use them for all HTTP exchanges that need to be secured.
- Membrane Service Proxy automatically takes care of using HTTPS for the HTTP exchanges 3, 4, 6 and 7.
- If potential users can connect via the open internet (or via any untrusted intermediary), use SSL for HTTP exchanges 1, 2, 5 and 10.
- Unless the network connection between Membrane Service Proxy and the web server hosting the secret resource is safe, use SSL for HTTP exchanges 8 and 9.
- If the user (identified by a session ID cookie) issues any further requests, only steps 5, 8, 9 and 10 will take place.
- If the session timed out, steps 3-5 might occur automatically, if Google decides that the user already has granted trust to access the user’s email address to Membrane.
You have seen how quickly OAuth2 authorization can be set up using Membrane Service Proxy.
As the communication between the OAuth2 authorization server (Google) and the resource server (Membrane and the secret resource) is not covered by the OAuth2 specification, this is Google-specific.
But as Membrane's oauth2 feature is modular in its source code design, it is easy to implement additional adapters connecting to other authorization services: For example, Amazon, Dropbox, Facebook, GitHub, Microsoft and Twitter all support OAuth 2.
Please let us know, if you run into any problems.