US10375073B2

Movatterモバイル変換

Info

Publication number: US10375073B2
Application number: US15/250,428
Authority: US
Inventors: Manjunatha D; Subramanian Krishnan; Harini MURUGAN
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2016-08-29
Filing date: 2016-08-29
Publication date: 2019-08-06
Also published as: US20180063140A1

Abstract

Techniques for generic authentication with arbitrary services are provided. A request to authorize with a first service, of a plurality of services, using the OAuth protocol, is received by a generic client library, from a first application. A set of parameters specific to an implementation of the OAuth protocol provided by the first service are identified in a configuration file. An HTTP request is generated based on the set of parameters identified in the data structure, and the first application is authorized with the first service via the OAuth protocol using the generated HTTP request.

Description

BACKGROUND

The present invention relates to computer software, and more specifically, to computer software which provides a configuration-based client for OAuth authorization with arbitrary services and applications.

OAuth is an open standard for authorization. Services (also referred to as applications) may use OAuth as a mechanism to authorize third party applications to access resources in the service on behalf of clients (e.g., users) without sharing a user's login credentials. For example, a service which allows users to create digital photo albums may use OAuth to access a user's digital images stored by an image hosting service without requiring the user to provide their login credentials with the image hosting service.

Developing an application which needs access to resources provided by other services entails configuring the application to implement the steps of the OAuth protocol to obtain tokens that can be used to perform other operations on the services. However, each service may provide a specific implementation of the OAuth protocol, which may include different parameters, HTTP methods, and the like. When an application needs to support multiple different services, the application must include the service-specific code required to interface with each service's OAuth implementation. As such, applications can become bloated with service-specific code that is difficult to maintain. Furthermore, adding new services to the application means the application code has to be built and re-deployed, leading to application downtime.

SUMMARY

In one embodiment, a method comprises receiving, from a first application by a second application, a request to authorize with a first service, of a plurality of services, using the OAuth protocol, identifying, in a data structure by the second application, a set of parameters specific to an implementation of the OAuth protocol provided by the first service, modifying, by the second application, a first parameter of the second application based on the set of parameters identified in the data structure, and authorizing, by the second application, the first application with the first service via the OAuth protocol using the modified first parameter.

In another embodiment, a system comprises a processor and a memory storing instructions, which when executed by the processor, performs an operation comprising receiving, from a first application by a second application, a request to authorize with a first service, of a plurality of services, using the OAuth protocol, identifying, in a data structure by the second application, a set of parameters specific to an implementation of the OAuth protocol provided by the first service, modifying, by the second application, a first parameter of the second application based on the set of parameters identified in the data structure, and authorizing, by the second application, the first application with the first service via the OAuth protocol using the modified first parameter.

In another embodiment, a computer-readable storage medium has computer-readable program code embodied therewith, the computer-readable program code executable by a processor to perform an operation comprising receiving, from a first application by a second application, a request to authorize with a first service, of a plurality of services, using the OAuth protocol, identifying, in a data structure by the second application, a set of parameters specific to an implementation of the OAuth protocol provided by the first service, modifying, by the second application, a first parameter of the second application based on the set of parameters identified in the data structure, and authorizing, by the second application, the first application with the first service via the OAuth protocol using the modified first parameter.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a system architecture which provides a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment.

FIG. 2 illustrates an example method to provide a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment.

FIG. 3 is a flow chart illustrating an example method to perform OAuth authorization using a generic client library, according to one embodiment.

FIG. 4 is a flow chart illustrating an example method to perform OAuth authorization using a generic client library, according to one embodiment.

FIG. 5 illustrates an example system which provides a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment.

DETAILED DESCRIPTION

Embodiments disclosed herein allow applications to perform OAuth authorization with arbitrary services by abstracting the service-specific details from the applications seeking to access the services. Generally, applications (also referred to as services) may be configured to interface with a single generic client library. The generic client library in turn interfaces with a data store that includes service-specific OAuth configuration information for each of a plurality of services. The generic client library may use the service-specific configuration information to make the hypertext transfer protocol (HTTP) calls required to complete the steps of the OAuth protocol. Once the steps of the OAuth protocol are complete, the application may use the resulting tokens to access resources provided by the services.

FIG. 1 illustrates asystem architecture100 which provides a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment. As shown, thesystem100 includes a plurality of applications101_1-N, ageneric client library102, a configuration file103, and a plurality of services104_1-N. The applications101_1-Nare representative of any type of computing application. The services104_1-Nare representative of any type of computing service that implements the OAuth authorization protocol to grant access toresources105 provided by the services104_1-N. Theresources105 are representative of any type of computing resource, such as user account information, images, videos, storage, services, and the like. For example, a service104₁may be an email service, and theresources105 for the service104₁include emails, calendar data, and other information related to the email accounts of a plurality of different users. In such an example, an application101₁may be a third-party email application that allows users to access email accounts provided by the email service104₁. Before accessing the emails andother resources105 provided by the email service104₁, the application101₁needs to be authorized with the service104₁using the OAuth protocol. Doing so allows the application101₁to access the accountspecific resources105 provided by the email service104₁without requiring the user to enter their credentials with the email service104₁(e.g., a login and password).

However, each service104_1-Nmay implement the OAuth protocol in different ways. For example, service104₁may require the applications101_1-Nto provide information using the HTTP GET method, while service104₂may require the applications101_1-Nto provide information using the HTTP POST method. Similarly, parameters names used by the services104_1-Nmay differ. Therefore, the applications101_1-Ncannot simply re-use code that was generated for the implementation of the OAuth protocol on service104₁with the implementation of the OAuth protocol on service104₂.

Advantageously, however, the applications101_1-Ninterface with thegeneric client library102, which in turn interfaces with the configuration file103. As shown, the configuration file103 is a data store which includes OAuth configuration information for the services104_1-N. Generally, the configuration file103 captures detailed information about each step of the OAuth protocol for each service104_1-N. For example, the configuration file103 may store, for each service104_1-N, uniform resource locators (URLs), methods, input parameters, output parameters, validation information, and binding information which specifies how parameters will be bound to a value at runtime (e.g., the environment, config, hard-coded, local variable, and global variable binding options). Although depicted as a single file, in at least one embodiment, multiple configuration files103 may be used, where each configuration file103 stores the OAuth configuration information for one of the services104_1-N. In at least one embodiment, the information stored in the configuration files103 are passed as input to thegeneric client library102.

Multiple versions of the OAuth protocol exist, and therefore, the configuration file103 may include information for each version of the OAuth protocol implemented by the services104_1-N. For example, the configuration file103 may include a template for version 1.0 of the OAuth protocol. The template for version 1.0 of the OAuth protocol may include a configuration section, a series of steps of version 1.0 of the OAuth protocol, parameter binding options, and validations. The configuration section may specify the client_id, client_secret, and redirect_uri parameters of version 1.0 of the OAuth protocol. The steps of version 1.0 of the OAuth protocol include a request step which requests a temporary token (e.g., getTmpToken), an authorizing step (e.g., authorize), a callback step (e.g., callback), and a step in which the requesting application101_Nreceives an access token from the services104_1-N(e.g., getToken). For each step in version 1.0 of the OAuth protocol, the configuration file103 may specify configuration parameters for the URL (e.g., a formatting or specific URL), method (e.g., GET or POST), input parameters for each step, and output parameters for each step. The parameter binding options in the configuration file103 specify how parameters are bound to variables (e.g., environment, global variable, local variable, config, and/or hard coded variables). The validation configuration information in the configuration file103 includes information used to validate data flowing in and/or out of each step of the OAuth protocol (e.g., the oauth_callback_confirmed value should be true after the request token step).

The configuration file103 may also include a template for version 2.0 of the OAuth protocol. The template for version 2.0 of the OAuth protocol may include a configuration section, the steps of version 2.0 of the OAuth protocol, parameter binding options, and validations. The configuration section may specify the client_id, client_secret, redirect_uri, and grant type (e.g., AUTH_CODE or RESOURCE_OWNER_PASSWORD_CREDENTIALS) parameters of version 2.0 of the OAuth protocol. The steps of version 2.0 of the OAuth protocol include an authorizing step (e.g., authorize), a callback step (e.g., callback), and a step in which the requesting application receives an access token from the services104_1-N(e.g., getToken). For each step in version 2.0 of the OAuth protocol, the configuration file103 may specify configuration parameters for the URL (e.g., a formatting or specific URL), method (e.g., GET or POST), input parameters for each step, and output parameters for each step. The parameter binding options in the configuration file103 specify how parameters are bound to variables (e.g., environment, global variable, local variable, config, and/or hard coded variables). The validation configuration information in the configuration file103 includes information used to validate data flowing in and/or out of each step of the OAuth protocol (e.g., the state specified in the authorize step should match the state returned in the callback step).

Thegeneric client library102 leverages the information stored in the configuration file103 to perform the steps of the OAuth protocol with each service104_1-Nwhile abstracting the service-specific implementation details from the applications101_1-N. For example, thegeneric client library102 may use the information stored in the configuration file103 to make the HTTP calls required by the OAuth protocol. Thegeneric client library102 may also use the parameter binding options to transfer values between each step of the OAuth protocol. For example, in version 2.0 of the OAuth protocol, the steps include authorize (an outbound HTTP call), callback (inbound), and getToken (outbound). As such, thegeneric client library102 may include an authorize function, a callback function, and a resolve function. The authorize function is invoked by the applications101_1-Nto begin the OAuth authorization process with one of the services104_1-N. Continuing with a previous example, the third party email application101₁may invoke thegeneric client library102 to perform OAuth authentication with the email service104₁. Based on the service name and corresponding configuration received from the configuration file103, the authorize function of thegeneric client library102 may perform the authorize step of version 2.0 of the OAuth protocol by binding the parameters as necessary. However, if the RESOURCE_OWNER_PASSWORD_CREDENTIALS parameter is set, the authorize function is not invoked. In such an embodiment, thegeneric client library102 captures the configuration information from the configuration file103 necessary to construct a dynamic page where a user can input login credentials, and seek authorization using the provided credentials.

Thegeneric client library102 may then invoke the callback function after the authorization step completes. Once invoked, the callback function performs state validation according to the configuration file103. Based on the parameters for each service104_1-Nin the configuration file103, the callback function creates a form object (if the authorization step was successful) or an error object (if the authorization step failed). If authorization was successful, the callback function creates a token object according to the configuration file103, and returns the token object. If authorization was not successful, the callback function constructs the error object according to the configuration file103 and returns the error object. The resolve function binds the values of parameters based on the binding option specified in the configuration file103 for each service104_1-N.

As new services104_Nbecome available (and/or begin supporting the OAuth protocol), users may update the configuration file103 with the service-specific implementation details that allow the applications101_1-Nto access these services without having to be re-coded to support the service-specific implementation details of each service104_N. Table I reflects an example of the configuration information in the configuration file103 for an example service, “Service A”, which includes information for the three steps of version 2.0 of the OAuth protocol as implemented by example Service A:

TABLE I

	{
	“Service A”: {
	“config”: {
	“client_id”: “30pkegzod4jy2z67jzdrvd5nicw6w4cz”,
	“client_secret”: “3D2ICKwQ2i2qZYv3cbWW1hQCJn0jNYCO”,
	“type”: “AUTH_CODE”,
	“redirect_uri”: “http://localhost:7890/oauth2/redirect/serviceA”
	},
	“steps”: [{
	“name”: “auth”,
	“seqnum”: 1,
	“url”: “https://example.com/api/oauth2/authorize”,
	“method”: “GET”,
	“input_params”: [{
	“name”: “response_type”,
	“value”: “code”,
	“type”: “query”
	}, {
	“name”: “client_id”,
	“value”: “$$config.client_id”,
	“type”: “query”
	}, {
	“name”: “redirect_uri”,
	“value”: “$$config.redirect_uri”,
	“type”: “query”
	}, {
	“name”: “state”,
	“value”: “$$serviceA.state”,
	“type”: “query”
	}]
	}, {
	“name”: “callback”,
	“seqnum”: 2,
	“url”: “$$config.redirect_uri”,
	“method”: “GET”,
	“validate”: {
	“key”: “$$serviceA.state”,
	“value”: “$$var.req.query.state”
	},
	“form_object”: [{
	“name”: “grant_type”,
	“value”: “authorization_code”
	}, {
	“name”: “client_id”,
	“value”: “$$config.client_id”
	}, {
	“name”: “client_secret”,
	“value”: “$$config.client_secret”
	}, {
	“name”: “code”,
	“value”: “$$var.req.query.code”
	}],
	“error_object”: [{
	“name”: “error”,
	“value”: “$$var.req.query.error”
	}, {
	“name”: “error_description”,
	“value”: “$$var.req.query.error_description”
	}]
	}, {
	“name”: “token”,
	“seqnum”: 3,
	“url”: “https://example.com/api/oauth2/token”,
	“method”: “POST”,
	“input_params”: [{
	“name”: “Accept”,
	“value”: “application/json”,
	“type”: “header”
	}, {
	“name”: “Content-Type”,
	“value”: “application/x-www-form-urlencoded”,
	“type”: “header”
	}, {
	“name”: “body”,
	“value”: “$$var.form_object”,
	“type”: “body”
	}],
	“output_params”: [{
	“name”: “access_token”,
	“value”: “$$var.body.access_token”,
	“type”: “body”,
	“statusCode”: 200,
	“success”: true
	}, {
	“name”: “refresh_token”,
	“value”: “$$var.body.refresh_token”,
	“type”: “body”,
	“statusCode”: 200,
	“success”: true
	}, {
	“name”: “error”,
	“value”: “$$var.body.error”,
	“type”: “body”,
	“statusCode”: 200
	}, {
	“name”: “error_description”,
	“value”: “$$var.body.error_description”,
	“type”: “body”,
	“statusCode”: 200
	}]
	}]
	}

The configuration file103 may have configuration information similar to that depicted in Table I for each of the services104_1-N, where values specific to each service104_Nare specified in the configuration file103. Furthermore, the configuration file103 may include configuration information for multiple versions of the OAuth protocol implemented by the services104_1-N(e.g., with information regarding each step of each version of the OAuth protocol).

Table II below reflects example code used to implement thegeneric client library102 in one embodiment. As shown, Table II reflects code that includes a resolve function, an authorize function, and a callback function, corresponding to version 2.0 of the OAuth protocol:

TABLE II

	‘use strict’;
	var request = require(‘request’);
	var state = { };
	function _resolve(key, config, vars) {
	function _bind(key, inpvar) {
	var out = inpvar;
	var tokens = key.split(“.”);
	for (var i = 0; i < tokens.length; ++i) {
	var t = tokens[i];
	out = out[t];
	}
	return out;
	}
	if (key.match(/ \$\$config/)) {
	var resolved_key = key.substring(9);
	//console.log(“:::”+resolved_key);
	return config[resolved_key];
	}
	if (key.match(/ \$\$env/)) {
	return process.env[key];
	}
	if (key.match(/ \$\$var/)) {
	var resolved_key = key.substring(6);
	//console.log(“:::”+resolved_key);
	return_bind(resolved_key, vars);
	}
	if (key.match(/ \$\$/)) {
	var resolved_key = key.substring(2);
	//console.log(“:::”+resolved_key);
	return _bind(resolved_key, state);
	}
	return key;
	}
	function authorize(app_name, app_config, res) {
	console.log(“authorize called for ” + app_name);
	console.log(JSON.stringify(app_config));
	var grant_type = app_config.config.type;
	var url;
	if (grant_type === ‘AUTH_CODE’) {
	url = app_config.steps[0].url;
	var input_params = app_config.steps[0].input_params;
	var delim = ‘?’;
	for (var i = 0; i < input_params.length; ++i) {
	var inp = input_params[i];
	if (inp.type === ‘query’) {
	url += delim + inp.name + ‘=’;
	url += _resolve(inp.value, app_config.config);
	delim = ‘&’;
	}
	}
	}
	console.log(url);
	res.statusCode = 302;
	res.setHeader(“Location”, url);
	res.end( );
	}
	function callback(app_name, app_config, req, res) {
	console.log(“callback called for ” + app_name);
	console.log(JSON.stringify(req.query));
	var grant_type = app_config.config.type;
	var vars = {
	‘req’: req,
	‘res’: res
	};
	var form = ”;
	var error;
	var validate = app_config.steps[1].validate;
	if (validate) {
	var key = _resolve(validate.key, app_config.config, vars);
	var value = _resolve(validate.value, app_config.config, vars);
	console.log(“::” + key + “::” + value);
	if (key !== value) {
	error = {
	error_description: ‘INVALID STATE’
	}
	};
	}
	var folist = app_config.steps[1].form_object;
	var eolist = app_config.steps[1].error_object;
	var delim = ”;
	for (var i = 0; i < folist.length; ++i) {
	var fo = folist[i];
	form += delim + fo.name + ‘=’;
	form += _resolve(fo.value, app_config.config, vars);
	delim = ‘&’;
	}
	console.log(“::” + form);
	for (var i = 0; i < eolist.length; ++i) {
	var eo = eolist[i];
	if (!error) error = { };
	error[eo.name] = _resolve(eo.value, app_config.config, vars);
	}
	//console.log(JSON.stringify(error));
	if (!error \|\| JSON.stringify(error) === ‘{ }’) {
	console.log(“reached here....”);
	var reqobj = {
	url: app_config.steps[2].url,
	method: app_config.steps[2].method
	};
	var headers = { };
	var inlist = app_config.steps[2].input_params;
	for (var i = 0; i < inlist.length; ++i) {
	var io = inlist[i];
	if (io.type === ‘body’) reqobj.body = form;
	if (io.type === ‘header’) headers[io.name] = io.value;
	}
	if (JSON.stringify(headers) !== ‘{ }’) reqobj.headers = headers;
	request(reqobj, function(error, response, body) {
	if (error) {
	console.log(error); //call error page
	res.error(error);
	}
	else {
	var outlist = app_config.steps[2].output_params;
	var output = { };
	var error2 = { };
	var vars2 = {
	‘body’: JSON.parse(body)
	};
	for (var i = 0; i < outlist.length; ++i) {
	var oo = outlist[i];
	//console.log(JSON.stringify(oo));
	if (oo.statusCode === response.statusCode) {
	if (oo.success) output[oo.name] = _resolve(oo.value,

app_config.config, vars2);

else error2[oo.name] = _resolve(oo.value, app_config.config,

vars2);

	}
	}
	}
	//console.log(JSON.stringify(output));
	if (JSON.stringify(error2) !== ‘{ }’) res.json(error2);
	else res.json(output);
	});
	}
	}
	module.exports.authorize = authorize;
	module.exports.callback = callback;
	module.exports.state = state;

Table III illustrates an example of source code in one of the applications101_Nwhich interfaces with thegeneric client library102 to use OAuth version 2.0 to authenticate with three example services, namely ServiceA, ServiceB, and ServiceC:

TABLE III

	var express = require(‘express’);
	var bodyParser = require(‘body-parser’);
	var _ = require(‘underscore’);
	var https = require(‘https’);
	var request = require(‘request’);
	var config = require(‘./oauth2_config.json’); //read from cloudant ultimately
	var oauth2 = require(‘./generic_oauth2.js’);
	//for each app init state - will be done in a generic for loop ultimately
	oauth2.state.ServiceA = {‘state’: ‘axRSj328!1’};
	oauth2.state.ServiceB = {‘state’: ‘9ijdefng3@’};
	oauth2.state.ServiceC = {‘state’: ‘h45fru(=k’};
	var http_host = (process.env.VCAP_APP_HOST \|\| ‘0.0.0.0’);
	var http_port = (process.env.VCAP_APP_PORT \|\| 7890);
	var app = express( );
	app.set(‘port’, http_port);
	app.set(‘host’, http_host);
	app.use(express.static(__dirname + ‘/public’));
	app.use(bodyParser.json( ));
	var server = app.listen(app.get(‘port’), app.get(‘host’), function( ) {
	console.log(‘Express server listening on ’ + server.address( ).address + ‘:’ +

server.address( ).port);

	});
	app.get(‘/oauth2/authorize/:app_name’, function(req, res) {
	var app_name = req.params.app_name;
	console.log(“Authorize called for ” + app_name);
	oauth2.authorize(app_name, config[app_name], res);
	});
	app.get(‘/oauth2/redirect/:app_name’, function(req, res) {
	var app_name = req.params.app_name;
	console.log(“Callback called for ” + app_name);
	oauth2.callback(app_name, config[app_name], req, res);
	});

FIG. 2 illustrates anexample method200 to provide a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment. As shown, themethod200 begins atblock210, where a user may define the templates for the configuration file103. As previously indicated, the templates may be for each version of the OAuth protocol. The templates may specify the configuration parameters, the steps of the OAuth protocol (and associated configuration information), how parameters are bound at runtime, and whether any validations need to be performed at each step of the OAuth process. Atblock220, thegeneric client library102 is configured to perform each step of the OAuth protocol according to the configuration information for each service104_1-Nstored in the configuration file103. Table II above depicts one example of source code for thegeneric client library102.

Atblock230, a user may add OAuth configuration and parameters for the services104_1-Nto the configuration file103. Table I above depicts an example of a configuration file103 for a generic service104_N. Atblock240, the applications101_1-Nare configured to interface with thegeneric client library102 to perform the steps of the OAuth authorization protocol. Table III above depicts one example of source code that may be included in the applications101_1-Nthat allows the applications101_1-Nto interface with thegeneric client library102.

FIG. 3 is a flow chart illustrating anexample method300 corresponding to block260 to perform OAuth authorization using thegeneric client library102, according to one embodiment. The example depicted inFIG. 3 corresponds to version 2.0 of the OAuth protocol. As shown, themethod300 begins atblock305, where thegeneric client library102 executes a loop including blocks310-380 for each step in version 2.0 of the OAuth protocol (e.g., the authorize, callback, and getToken steps). Atblock315, thegeneric client library102 receives the configuration information for the current step from the configuration file103. In at least one embodiment, thegeneric client library102 reads the information from the configuration file103 via a read API provided by the configuration file103. In the example configuration information depicted in Table I, the configuration information for the authorization step of the OAuth protocol includes a URL, method, and input parameters. The URL specifies where thegeneric client library102 should direct an HTTP call, while the method indicates which HTTP method should be used in composing the HTTP call (in this example, the HTTP GET method). The names of the input parameters include a response_type, client_id, redirect_uri, and state, while each of these input parameters are query parameters. Thegeneric client library102 may use these input parameter names to construct an HTTP call as part of the authorization step. As shown in Table I, the input parameter response_type is hard-coded (e.g., static) variable with a value of “code”, while input parameters client_id, redirect_uri, and state are dynamically determined by thegeneric client library102 at runtime.

Returning to block315, if the current step is an outbound step, thegeneric client library102 proceeds to block335. Atblock335, thegeneric client library102 binds the parameters of the current step of the OAuth protocol per the configuration information in the configuration file103 for the current step of the OAuth protocol as implemented by the service104_N. Atblock340, thegeneric client library102 constructs an HTTP request which includes header, body, and query portions per the information for the current step of the OAuth protocol implemented by the service104_Nin the configuration file103. Atblock345, thegeneric client library102 makes the HTTP call according to a format (e.g., HTTP GET, HTTP POST, or HTTP PUT) specified in the configuration file103 for the service104_N. Atblock350, thegeneric client library102 may validate a response received from the service104_Nresponsive to the HTTP call. Thegeneric client library102 validates the response based on rules for validating the response for the service104_Nstored in the configuration file103. Generally, the recipient of an HTTP request (e.g., the HTTP call issued at block345) may respond with an HTTP response. Therefore, the service104_Nmay respond to the HTTP call ofblock345 with any valid HTTP response (e.g., 200 success, 500 failure, etc.). As such, the configuration file103 may include information on how to parse each HTTP response received from each service104_N. For example, as shown in Table I, the validation for ServiceA is based on a specified key/value pair that are returned by service A. Furthermore, the validation atblock350 may be optional depending on the OAuth implementation of each service104_N. Therefore thegeneric client library102 may skip the validation if the configuration file103 indicates that the service104_Ndoes not implement validation.

Atblock355, thegeneric client library102 determines whether the validated response indicates the response was successful. Thegeneric client library102 may include code which implements rules for validating responses. For example, as shown in Table II, thegeneric client library102 applies the rules to the key/value pairs identified in the configuration information for ServiceA above. If the response was successful, thegeneric client library102 proceeds to block360, where thegeneric client library102 parses values provided by the service104_Nin the HTTP response per the information corresponding to the response for the service104_Nin the configuration file103. Atblock365, thegeneric client library102 stores the values parsed atblock360 for future use. Thegeneric client library102 may then proceed to block380.

Returning to block355, if the response was not successful (e.g., the service104_Nreturns an indication of an error), thegeneric client library102 proceeds to block370. Atblock370, thegeneric client library102 parses the error based on rules for parsing the error stored in the configuration file103 for the service104_N. Atblock375, thegeneric client library102 returns an indication of an error.

Atblock380, thegeneric client library102 determines whether more steps of the OAuth protocol remain. If more steps remain, thegeneric client library102 returns to block305 to continue the steps of the OAuth protocol. If no more steps remain, the OAuth authorization process has completed (or was terminated based on an error), and themethod300 ends.

FIG. 4 is a flow chart illustrating anexample method400 corresponding to block260 to perform OAuth authorization using a generic client library, according to one embodiment. The example depicted inFIG. 4 corresponds to version 1.0 of the OAuth protocol. As shown, themethod400 begins atblock405, where thegeneric client library102 executes a loop including blocks410-485 for each step in version 1.0 of the OAuth protocol (e.g., the getTmpToken, authorize, callback, and getToken steps). Atblock415, thegeneric client library102 receives the configuration information for the current step from the configuration file103. In at least one embodiment, thegeneric client library102 reads the information from the configuration file103 via a read API provided by the configuration file103.

Returning to block415, if the current step is an outbound step, thegeneric client library102 proceeds to block435. Atblock435, thegeneric client library102 binds the parameters of the current step of the OAuth protocol per the configuration information in the configuration file103 for the current step of the OAuth protocol as implemented by the service104_N. For example, if the configuration file103 indicates a variable is dynamic, thegeneric client library102 dynamically generates and binds the variable. Atblock440, thegeneric client library102 signs the request parameters based on the parameters stored in the configuration file103 for the current step of version 1.0 of the OAuth protocol for the target service104_N. At block445, thegeneric client library102 constructs an HTTP request which includes header, body, and query portions per the information for the current step of the OAuth protocol implemented by the service104_Nin the configuration file103. Atblock450, thegeneric client library102 makes the HTTP call according to a format (e.g., HTTP GET, HTTP POST, or HTTP PUT) specified in the configuration file103 for the service104_N. For example, the configuration file103 for the target service104_Nmay indicate that the service104_Nrequires query parameters to be passed via the HTTP POST method. Atblock455, thegeneric client library102 may validate a response received from the service104_Nresponsive to the HTTP call. Thegeneric client library102 validates the response based on rules for validating the response for the service104_Nstored in the configuration file103. As previously indicated, the recipient of an HTTP request (e.g., the HTTP call issued at block450) may respond with an HTTP response. Therefore, the service104_Nmay respond to the HTTP call ofblock450 with any valid HTTP response (e.g., 200 success, 500 failure, etc.). As such, the configuration file103 may include information on how to parse each HTTP response received from each service104_N.

Atblock460, thegeneric client library102 determines whether the validated response indicates the response was successful. If the response was successful, thegeneric client library102 proceeds to block465, where thegeneric client library102 parses values provided by the service104_Nin the response per the information corresponding to the response for the service104_Nin the configuration file103. Atblock470, thegeneric client library102 stores the values parsed atblock465 for future use. Thegeneric client library102 may then proceed to block480.

Returning to block460, if the response was not successful (e.g., the service104_Nreturns anHTTP500 message indicating an error), thegeneric client library102 proceeds to block475. Atblock475, thegeneric client library102 parses the error based on rules for parsing the error stored in the configuration file103 for the service104_N. Atblock480, thegeneric client library102 returns an indication of an error.

Atblock485, thegeneric client library102 determines whether more steps of version 1.0 of the OAuth protocol remain. If more steps remain, thegeneric client library102 returns to block405 to continue the steps of the OAuth protocol. If no more steps remain, the OAuth authorization process has completed (or was terminated based on an error), and themethod400 ends.

FIG. 5 illustrates anexample system500 which provides a configuration based client for OAuth authorization with arbitrary services and applications, according to one embodiment. Thenetworked system500 includes acomputer502. Thecomputer502 may also be connected to other computers via anetwork530. In general, thenetwork530 may be a telecommunications network and/or a wide area network (WAN). In a particular embodiment, thenetwork530 is the Internet.

Thecomputer502 generally includes aprocessor504 which obtains instructions and data via abus520 from amemory506 and/or astorage508. Thecomputer502 may also include one or morenetwork interface devices518,input devices522, andoutput devices524 connected to thebus520. Thecomputer502 is generally under the control of an operating system (not shown). Examples of operating systems include the UNIX operating system, versions of the Microsoft Windows operating system, and distributions of the Linux operating system. (UNIX is a registered trademark of The Open Group in the United States and other countries. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.) More generally, any operating system supporting the functions disclosed herein may be used. Theprocessor504 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs. Thenetwork interface device518 may be any type of network communications device allowing thecomputer502 to communicate with other computers via thenetwork530.

Thestorage508 is representative of hard-disk drives, solid state drives, flash memory devices, optical media and the like. Generally, thestorage508 stores application programs and data for use by thecomputer502. In addition, thememory506 and thestorage508 may be considered to include memory physically located elsewhere; for example, on another computer coupled to thecomputer502 via thebus520.

Theinput device522 may be any device for providing input to thecomputer502. For example, a keyboard and/or a mouse may be used. Theinput device522 represents a wide variety of input devices, including keyboards, mice, controllers, and so on. Furthermore, theinput device522 may include a set of buttons, switches or other physical device mechanisms for controlling thecomputer502. Theoutput device524 may include output devices such as monitors, touch screen displays, and so on.

As shown, thememory506 contains the applications101_1-Nand thegeneric client library102. In at least one embodiment, thegeneric client library102 is an integrated component of the applications101_1-N. As shown, thestorage508 contains the configuration file103. As shown, a plurality ofservice providers550 provide one or more of the services104_1-N, which in turn provide access to theresources105 to the applications101_1-N. Generally, thesystem500 is configured to implement all methods, source code, systems, and apparatuses described above.

Advantageously, embodiments disclosed herein provide techniques to efficiently scale applications to support the various implementations of the OAuth protocol by a plurality of different service providers. By abstracting the implementation details from the applications, the applications need not be aware of the specific details of each implementation. Instead, thegeneric client library102 may reference the configuration file103 to identify the implementation details for each service, and may complete the steps of the OAuth protocol on behalf of the applications101_1-Nto authorize with the services104_1-N.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

In the foregoing, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the recited features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the recited aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

Aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.”

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications or related data available in the cloud. For example, thegeneric client library102 could execute on a computing system in the cloud. In such a case, thegeneric client library102 may reference the configuration file103 which is stored at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.