WO2013186070A1

WO2013186070A1 - A method and a system for providing access to protected resources via an oauth protocol

Info

Publication number: WO2013186070A1
Application number: PCT/EP2013/061359
Authority: WO
Inventors: David LOZANO; Diego GONZÁLEZ; Jorge LORENZO; José Antonio Rodriguez; Santiago PRIETO MARTÍN
Original assignee: Telefonica, S.A.
Priority date: 2012-06-12
Filing date: 2013-06-03
Publication date: 2013-12-19

Abstract

The method, comprising providing access to protected resources to an application of a computing device through an OAuth 1.0 infrastructure; the method comprises providing said access to protected resources through an OAuth 1.0 infrastructure to said application supporting OAuth 2.0 protocol by means of an intermediary entity adapting OAuth 2.0 protocol to OAuth 1.0 protocol, and vice versa. The system is adapted for implementing the method.

Description

A method and a system for providing access to protected resources via an

OAuth protocol

Field of the art

The present invention generally relates, in a first aspect, to a method for providing access to protected resources via an OAuth protocol, and more particularly to a method which provides a solution for migrating from OAuth 1.0 to OAuth 2.0 infrastructures.

A second aspect of the invention relates to a system arranged to implement the method of the first aspect.

Prior State of the Art

In the last years the Internet world has experienced an explosion of web APIs/web services that open up service providers' functionalities to other sites and, in many cases, to individual developers, thus, allowing them to quickly build new services or enrich already existing ones through the inclusion and combination of remotely exposed functionalities. Nowadays, this is one of the major trends in the Internet and it is expected to keep growing and evolving, progressively addressing more sophisticated and dynamic scenarios.

Opening up APIs implies different issues that must be properly solved from a technical point of view in order to achieve really useful and suitable results. One of the main problems to be solved is security and, especially, end-user's privacy. Basically, Internet applications should only access service providers' functionalities after having correctly authenticated and after having received the explicit consent or authorization from the owner of the resources to be accessed, without the need for the resource owner (typically an end-user) to share his/her identity or credentials with the application. As a solution to this problem, the new OAuth 1.0 [1] standard has emerged in the last years and now the Internet community and IETF are working in the second version (OAuth 2.0 [2]) of this standard, which is expected to also become an official standard very soon. Although OAuth 2.0 maintains the overall approach established by OAuth 1.0, it must be noted that it replaces and obsoletes the previous protocol version. Hence, the second version is not backward, nor forward compatible with the first version, meaning that OAuth 1 .0 clients cannot directly access OAuth 2.0 servers and vice versa. In this scenario with two parallel versions of the OAuth protocol, enterprises already supporting OAuth 1.0, but wanting to evolve and support the new OAuth 2.0 standard, face different technical and economic issues. One of the major issues is that the support for "legacy" applications using OAuth 1.0 must be maintained. These applications are already working and generating profits and, in many cases, they are installed in end-user devices, therefore, updating and re-installing them to support OAuth 2.0 is not an easy option. After acknowledging that the OAuth 1 .0 support has to be maintained, enterprises also need to find ways to add OAuth 2.0 support in the shortest possible time, with the less possible cost and with the highest possible re- usage of its already existing OAuth 1.0 infrastructure, in order to reduce duplicated provisioning, operation and maintenance procedures and costs.

The main current existing technologies are the OAuth 1.0 Protocol [1] that is standardized by the IETF (http://www.ietf.org/) and the OAuth 2.0 Protocol [2] which is under standardization process by the IETF, but (at the time of writing this document) expected to become an official standard very soon.

Both OAuth 1.0 and 2.0 define an open protocol to allow secure API authorization in a simple and standard method for native and web applications, available both for Trusted and Non-Trusted Consumers (Clients). OAuth, as specified, is directly applicable to grant access to resources in REST [8] web services, but may also be used for example in SOAP-based web services.

In order for the client to access resources, it first has to obtain by means of the OAuth API, permission from the resource owner (e.g. final user). This permission is expressed in the form of a token and matching shared-secret. The purpose of the token is to make it unnecessary for the resource owner to share its credentials with the client. Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and can be revoked independently.

In short, the main purpose of the OAuth API is to provide the means for the consumer to gain a valid Access Token.

The interactions followed by OAuth 1 .0 are summarized in Figure 1 .

In this 3-legged access mode, there are two tokens with crucial roles:

- In the first place, Request Token is used as a reference within the delegated authorization procedures. More concretely, according to [1], Request Tokens are used by the Consumer to ask the User to authorize access to the Protected Resources. Then, the User-authorized Request Token, that is recommended to have a limited lifetime, is exchanged for an Access Token.

- Finally, this Access Token is used by the Consumer to access the APIs on behalf of the User, instead of using the User's credentials (e.g. user and password). Access Tokens may limit access to certain APIs or even resources within a given API.

In OAuth 2.0, the Request Token concept disappears. Thus, the flow starts with the Authorization Request to the Service. In this request, instead of including the Request Token, the consumer identification is sent, as shown in Figure 2.

The flow in Figure 2 describes the OAuth 2.0 scenario called "Authorization

Code". In addition, OAuth 2.0 is specifying other scenarios:

- Implicit Grant: The implicit grant type is suitable for clients incapable of maintaining their client credentials confidential (for authenticating with the authorization server) such as client applications residing in a user- agent (e.g. browser).

- Resource Owner password credentials: The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as its computer operating system or a highly privileged application.

- Client Credentials: The client can request an Access Token using only its client credentials when the client is requesting access to the protected resources under its control, or those of another resource owner which has been previously arranged with the authorization server (the method of which is beyond the scope of the OAuth 2.0 specification).

Existing solutions

Many work, solutions and tools have been developed on both versions of the protocol, but OAuth 1.0 and 2.0 are systematically considered as parallel, independent and non-compatible solutions. No solutions for re-using OAuth 1.0 support in order to expose OAuth 2.0 have been identified in current, public state-of-the-art so far.

Problems with existing solutions

As already explained, when evolving to OAuth 2.0, backwards support for OAuth 1.0 is a must in many cases. Considering the support of OAuth 1.0 and OAuth 2.0 as independent issues presents different problems and drawbacks derived from the need to build, manage and operate two parallel infrastructures and their associated processes. The main drawbacks are:

- Increased time for migrating to the newer version.

- Increased costs associated to the migration to OAuth 2.0.

- Increased complexity and reduced homogeneity, as two parallel solutions must be maintained.

Re-using current OAuth 1.0 infrastructures as much as possible helps solving the above problems. The present invention provides a technical solution for making it possible.

Description of the Invention

It is necessary to offer an alternative to the state of the art which covers the gaps found therein, particularly related to the lack of proposals which really allows exposing OAuth 2.0 infrastructures using the existing OAuth 1.0 infrastructures without modifying these 1.0 infrastructures in any way and with the possibility of maintaining them as the main point for security control, operation and maintenance.

To that end, the present invention provides, in a first aspect, a method for providing access to protected resources via an OAuth protocol, the method comprising providing access to protected resources to an application of a computing device through an OAuth 1 .0 infrastructure.

The method comprises providing said access to protected resources through an OAuth 1.0 infrastructure to said application supporting OAuth 2.0 protocol by means of an intermediary entity adapting OAuth 2.0 protocol to OAuth 1 .0 protocol, and vice versa.

In a preferred embodiment, the method comprises providing said access to said protected resources without modifying said OAuth 1.0 infrastructure.

Other embodiments of the method of the first aspect of the invention are described according to appended claims 2 to 14, and in a subsequent section related to the detailed description of several embodiments.

A second aspect of the present invention concerns to a system for providing access to protected resources via an OAuth protocol, said system comprising a OAuth 1.0 infrastructure providing said access to said protected resources and a computing device with an application supported by OAuth protocol, for accessing said protected resources. The system wherein said application is supported by OAuth 2.0 protocol it further comprises an intermediary entity arranged between said computing device and said OAuth 1.0 infrastructure and configured for providing to said application of said computing device said access to said protected resources by adapting OAuth 2.0 protocol to OAuth 1.0 protocol, and vice versa.

The system of the second aspect of the invention is adapted to implement the method of the first aspect.

An embodiment of the system of the second aspect of the invention is described according to appended claim 16, and in a subsequent section related to the detailed description of several embodiments.

Brief Description of the Drawings

The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached drawings, which must be considered in an illustrative and non-limiting manner, in which:

Figure 1 shows an example of the interactions followed by OAuth 1 .0.

Figure 2 shows an example of the interactions followed by OAuth 2.0.

Figure 3 shows the OAuth 2.0 Bridge architecture, according to an embodiment of the present invention.

Figure 4 shows the diagram of the authorization code flow on top of an OAuth

1.0 infrastructure, according to an embodiment of the present invention.

Figure 5 shows the diagram of the implicit grant flow on top of an OAuth 1 .0 infrastructure, according to an embodiment of the present invention.

Figure 6 shows the diagram of accessing protected resources exposed by OAuth 1 .0 infrastructure, according to an embodiment of the present invention.

Figure 7, shows the flow diagram for refreshing an access token with the help of the OAuth 2.0 Bridge, according to an embodiment of the present invention.

Detailed Description of Several Embodiments

The present invention provides a solution to expose OAuth 2.0 on top of existing OAuth 1 .0 infrastructures, without having to modify the OAuth 1 .0 support within the existing infrastructure (i.e. without modifying existing Authorization and

Resources Servers).

The basic concept of the invention is to use an intermediary entity (i.e. a bridge) that adapts standard OAuth 2.0 into standard OAuth 1.0. To perform such adaptation, the OAuth Bridge basically behaves as the external client from OAuth 1.0 infrastructure's perspective, while it behaves as OAuth 2.0 Authorization and Resource Server from external OAuth 2.0 client's perspective. The final responsibility of generating, maintaining and validating identifiers, credentials and tokens as well as enforcing the adequate access scope to protected resources remains at the existing OAuth 1.0 infrastructure. In summary, the OAuth 2.0 Bridge behaves as an intermediary enabling OAuth 2.0 without having to modify existing OAuth 1.0 Authorization and Resource Servers, as graphically summarized in Figure 3.

In addition, OAuth 1.0 clients will still use the existing Oauth 1.0 infrastructure, without passing through the bridge. Thus no change on existing Oauth 1.0-based services is required.

More specifically, to achieve the above goals, the OAuth 2.0 Bridge has to:

Intermediate and adapt between the flows of the two OAuth versions, as explained in the following table:

PROTOCOL OAuth 2.o OAuth 1.0

STEPS

This step does not exist in The OAuth Bridge performs

Obtain OAuth 2.0. It is hidden from this operation towards the ; Temporary external OAuth 2.0 clients by OAuth 1.0 infrastructure as the credentials (i.e. the OAuth Bridge very first step when an OAuth request token) 2.0 access authorization

request is received.

Performed following the This step, comprising final user OAuth 2.0 standard towards authentication and : external clients and end authorization, is shared among ; users. The OAuth Bridge the two protocol flows. It is actually encapsulates the done only once through an following OAuth 1.0 steps authentication and behind it: authorization web page.

Obtain • Obtain Request As result, after authenticating

the user and receiving her authorization Token

authorization, OAuth 1.0

• Obtain authorization Request Tokens are authorized ;

at the OAuth 1.0 infrastructure

• Obtain Access Token, (Authorization Server) and an ; in case of the implicit associated Authorization Code : grant flow (known as verification code in

OAuth 1.0) is generated. This : code is valid for both protocol ; versions.

When applicable Performed by the OAuth ;

Obtain access

(authorization code flow), Bridge, within one of the token

performed following the following options: OAuth 2.0 standard towards

external clients. as direct result of

receiving an individual OAuth 2.0 Access Token request (i.e. authorization code flow), or

as part of the authorization step for the OAuth 2.0 implicit

Table 1.- Protocol flow adaptation from OAuth 2.0 to 1.0

Translate between the syntax of both protocol versions, considering the translation of requests coming from external clients into OAuth 1.0 requests, that are sent towards the existing infrastructure, as well as the adaptation of OAuth 1 .0 responses into OAuth 2.0 responses in the reverse direction (from the infrastructure towards external clients).

In order to limit the amount of unauthorized or malformed requests arriving at the OAuth 1 .0 infrastructure, the OAuth 2.0 Bridge validates OAuth 2.0 requests coming from external clients: validate the requests are well formed, check if the received access token is valid and was issued for the external client sending the request, validate signatures when applicable (depending on the access token type) and, optionally, make further access security checking, such as access scope validations, etc.

Correctly form and sign OAuth 1.0 requests, using appropriate credentials and token values and secrets, before sending them towards the OAuth 1 .0 infrastructure. To carry out its functionalities, the OAuth Bridge must be able of correctly interacting with the underlying OAuth 1 .0 infrastructure, especially with the Authorization Server, for querying, handling and, optionally, storing client identifiers, client credentials, client registration details, Token values, Token secrets and Authorization Codes. There are different options in this regard, for example, the OAuth Bridge can simply query the OAuth 1.0 infrastructure for client and token information whenever a new OAuth 2.0 request arrives. Alternatively, in order to improve performance, it may query and then cache this information temporarily or permanently. This document, as an example, considers the option of temporarily caching the information queried from the OAuth 1.0 infrastructure (client identifiers and credentials, token values and secrets, etc), but the overall concept of the invention is the same independently of the option chosen in this regard or the means used to interact with the underlying OAuth 1.0 infrastructure.

Moreover, OAuth 2.0 tokens may be of different types and may have the same or different values (and secrets, when applicable depending on the token type) than those generated in the OAuth 1.0 infrastructure. In any case, there must always exist a 1 to 1 mapping between OAuth 1 .0 and OAuth 2.0 Access Tokens, as both are the expression of the same delegated access authorization provided by the final user. The OAuth 2.0 Bridge must therefore be ready to correctly handle this mapping and, as result, use the correct Access Token on both communication sides (OAuth 2.0 Access Tokens towards external client vs OAuth 1.0 Access Tokens towards the existing infrastructure). In any case, the overall concept of the invention is the same independently of reusing token values (and secrets when applicable) or generating new values for the OAuth 2.0 side.

As explained previously, it is worth highlighting that the OAuth 2.0 Bridge also needs to provide the OAuth 2.0 authorization endpoint: a web page that interacts with the existing OAuth 1.0 Authorization Server in order to authenticate final users and authorize the access for external applications (also known as AA Portal: Authentication and Authorization Portal). As a matter of implementation, this web page can be implemented as an integral part of the OAuth 2.0 Bridge, or it can be implemented using an external web server, provided that it can correctly interact and pass information between the OAuth 1.0 Authorization Server and the OAuth 2.0 Bridge. The present document explicitly considers the option of providing this web page at an external web server, detailing how it has to interact and pass information between the different involved elements. Anyway, the overall concept of the invention is the same independently of the option chosen in this regard.

Finally, proxy the access to OAuth 1.0 Protected Resources from the URLs exposed by the bridge itself, which are protected by OAuth 2.0. The bridge must therefore know how the URLs it exposes map to OAuth 1.0 Protected Resource URLs as well as how to use the OAuth 1.0 Temporary Credentials and Token endpoints. This can be achieved in different ways, not affecting the basic idea of the present invention. For example, manual URL configuration could be used, or automatic rules may be applied to convert one set of URLs into another set of URLs, etc.

The operation details of operation of the OAuth 2.0 Bridge for the different protocol flows are explained in the following. This description uses OAuth 2.0 terminology for referring to entities and protocol elements. In order to correctly understand it, also from OAuth 1.0 perspective, the following terminology mapping is to be considered:

Table 2.- Map of OAuth terms

It must be noted that the client_secret can be any kind of credential, as configured during client registration process (textual password, HMAC-SHA1 key, a certificate or others).

This section specifies the detailed technical operation of the OAuth 2.0 Bridge, considering:

How to map and handle Access Tokens on both communications sides. Diagrams and associated descriptions for the following OAuth 2.0 protocol flows: o Authorization code o Implicit grant - Additionally, two further diagrams are provided: o Refreshing OAuth 2.0 Access Tokens (this is an optional flow) o Accessing protected resources, once the client has obtained a valid Access Token

For the sake of clarity, within the following flow diagrams, OAuth 2.0 standard messages [2] are represented by non-dotted lines, OAuth 1.0 standard messages [1] are represented by single dotted-lines and, finally, double dotted lines (with dots of two different lengths) are used to represent non-standard interactions among the OAuth 2.0 Bridge, the Authentication&Authorization Portal and the OAuth 1 .0 infrastructure. These latter interactions can be implemented following different messages syntax, but its semantics is as specified in the diagrams and associated descriptions.

It is assumed that the client needs to be registered with the OAuth 1 .0 infrastructure before the next procedures can take place. This registration may be done through different approaches, out of the scope, but compatible with the present invention.

Mapping Access Tokens between OAuth 1.0 and 2.0

The OAuth 2.0 Bridge must be capable of mapping Access Tokens, and associated details, between both communication sides. To do so, the OAuth 2.0 Bridge maintains a set of mapping tables that interrelate: - Each clientjd with its corresponding client_secret.

Each clientjd with one or more Access Tokens generated on the OAuth 1 .0 side. For each Access Token generated on the OAuth 1.0 side, the following details are stored: o Token value o Token secret o Expiration time (optional) o Access scope (optional) o Signing schemes associated to the Access Token - Each Access Token generated on the OAuth 1 .0 side with an associated Access Token generated on the OAuth 2.0 side [3] [4]. For each Access Token generated on the OAuth 2.0 side, the following details are stored: o Token value o Token type o Token secret (if applicable for the Token type) o Expiration time (optional) o Refresh Token associated to the Access Token (optional) o Access scope (optional) o Signing schemes associated to the Access Token (optional)

In general, if token values are re-used between both sides, then this table can be stored permanently of just cached for a freely chosen period of time, as Access Token details can be queried from OAuth 1.0 Authorization Server when received from the OAuth 2.0 side. On the other hand, if token values differ on each side, the table needs to be stored at least for a period of time equal or greater than the expiration time of the OAuth 1 .0 Access Token (meaning permanent storage for perpetual OAuth 1.0 Access Tokens). Note that when Refresh Tokens are used, then Access Token values are never the same on both sides.

As later explained in the following procedures, entries in this table may be deleted whenever the OAuth 1.0 Access Token is known to have expired or have been revoked, as directly indicated by the OAuth 1.0 Authorization Server when trying to recover Access Token details or as inferred from 401 error responses from OAuth 1 .0 Protected Resources. Authorization code flow

The following diagram shows how the OAuth 2.0 Bridge makes it possible to offer the standard OAuth 2.0 - authorization code flow on top of an OAuth 1.0 infrastructure.

1. As considered by OAuth 2.0 specification, the first step is to redirect the user (via the user-agent) to the authorization endpoint, in this case, the AA Portal. This redirection includes query parameters as considered by OAuth 2.0 specifications. More specifically, it indicates response type = code to signal that the OAuth 2.0 Authorization Code flow must be used.

2. In order to later authorize the access on the OAuth 1.0 infrastructure, the AA portal immediately sends a message to the OAuth 2.0 Bridge signaling the need to obtain an OAuth 1.0 Request Token. This message includes the clientjd and, when included by the client in the previous step, the redirect_uri. 3. If the OAuth 2.0 Bridge does not have the client_secret in its cache (as stored from previous accesses), it queries that information from the OAuth 1 .0 Authorization Server. It also queries the redirect_uri if not sent from the AA Portal and also not in cache. The OAuth 1.0 Authorization Server responds with the requested information. 4. The OAuth 2.0 Bridge temporarily caches the clientjd and the redirect_uri for later usages. The time this information will be maintained in the cache should be reconfigurable, so that the performance can be optimized against memory usage.

NOTE: the OAuth 2.0 Bridge may also need to know further information on the client, such as signature method to be used against OAuth 1.0 infrastructure, allowed Protected Resources and other details typically set up during client registration. All this information is actually handled by the OAuth 1.0 and should also be queried and cached by the bridge, along with the client_secret and redirect_uri, as explained above. 5. Using the information received from the AA Portal {clientjd, redirect_uri) plus the client_secret, the OAuth 2.0 Bridge sends a standard OAuth 1.0 Request Token request towards the OAuth 1.0 Authorization Server. The server responds with the Request Token and associated secret. The OAuth 2.0 Bridge temporarily caches the received Request Token, and the secret, in association with the clientjd. The time for caching this token/secret should also be configurable, independently from the caching time for the clientjd. The OAuth 2.0 Bridge immediately responds the AA portal with the obtained Request Token. Now, in response for step 1 , the AA Portal indicates the user must authenticate. The user authenticates. If this process fails, the flow is blocked here. Otherwise, proceed with next steps. The user is asked for authorization for the application identified by clientjd. If included in step 1 , the AA Portal considers the scope parameter to inform the user of the access scope requested by the application (e.g. access only to some resources or specific parts of resources). If the user denies the authorization, the flow is blocked here. If the user grants the authorization, proceed with next steps.

The AA Portal informs the OAuth 1 .0 Authorization Sever about the authorization provided by the end user, including the granted access scope. The OAuth 1.0 Authorization Server responds with the associated Authorization Code. All this communication takes places through the OAuth 2.0 Bridge, which acts as a proxy or relay between the two entities, so that the OAuth 2.0 Bridge can also get the Authorization Code generated by the OAuth 1.0 Authorization Server. The OAuth 2.0 Bridge caches the Authorization Code in association to the Request Token and the corresponding Token Secret and Clientjd.

As specified by OAuth 2.0, the AA Portal redirects the user (via the user-agent) back to the external client. This redirection includes the Authorization Code and the state parameter (this latter, if provided by the client itself in step 1 ). 14. Following OAuth 2.0 specs, the client sends an Access Token Request towards the OAuth 2.0 Bridge (to the Token endpoint), signaling the "authorization_code" grant type and the other standard parameters (including the Authorization Code). 15. The OAuth 2.0 Bridge validates the request is syntactically valid and, based on the information stored in its cache, it also validates that the client_secret and the redirect_uri are valid for that clientjd. Additionally, it also validates that the received Authorization Code was actually issued for that clientjd.

16. Following OAuth 1 .0 standards, the OAuth 2.0 Bridge sends an Access Token request towards the OAuth 1 .0 Authorization server. All the information required to correctly sign the request (cliendjd, client_secret, Request Token and Request Token secret) is taken from bridge internal cache. Specifically, the Request Token and the Request Token Secret to be used are those associated to the received Authorization Code, as stored in previous steps. If the Request Token has already expired or it is not present, the request received in step 14 is rejected with an appropriate error code. The OAuth 2.0 Bridge also has to include the Authorization Code received in step 14. If the Authorization Code is valid, the OAuth 1.o Authorization server responds with a valid Access Token plus an associated secret. If the Authorization Code is invalid, the request is rejected and this error is sent back to the client by the bridge.

17. The OAuth 2.0 Bridge responds the client, following one of the next options: o In case no Refresh Tokens are to be used, the Access Token sent to the client may be the one received from the OAuth 1 .0 Authorization Server, or it may be another value generated by the bridge itself. Additionally, the bridge also generates further details for the OAuth 2.0 side, such as token type, expiration information and, in case the token type requires a secret on the OAuth 2.0 side (e.g. MAC tokens [4]), it also includes the secret (e.g. as mac_key). o In case Refresh Tokens are to be used, the Refresh Token sent to the client may be the Access Token received from the OAuth 1 .0

Authorization Server, or it may be another value generated by the bridge itself. Furthermore, the bridge then generates, on its own, an OAuth 2.0 Access Token value and associated expiration time and secret, in case this latter secret is necessary depending on the Access Token type.

18. The OAuth 2.0 Bridge stores the Access Token details, for both communication sides, in its mapping table.

Implicit grant flow

The following diagram shows how the OAuth 2.0 Bridge makes it possible to offer the standard OAuth 2.0 - implicit grant flow on top of an OAuth 1.0 infrastructure.

1. As considered by OAuth 2.0 specification, the first step is to redirect the user (via the user-agent) to the authorization endpoint, in this case, the AA Portal.

This redirection includes query parameters as considered by OAuth 2.0 specifications. More specifically, it indicates response_type = token to signal that the OAuth 2.0 Implicit Grant flow must be used.

2. In order to later authorize the access on the OAuth 1.0 infrastructure, the AA portal immediately sends a message to the OAuth 2.0 Bridge signaling the need to obtain an OAuth 1.0 Request Token. This message includes the clientjd and, optionally, the redirect_uri.

3. If the OAuth 2.0 Bridge does not have the client_secret in its cache (as stored from previous accesses), it queries that information from the OAuth 1 .0 Authorization Server. It also queries the redirect_uri if not sent from the AA

Portal and also not in cache. The OAuth 1.0 Authorization Server responds with the requested information.

4. The OAuth 2.0 Bridge temporarily caches the clientjd and the redirect_uri for later usages. The time this information will be maintained in the cache should be reconfigurable, so that the performance can be optimized against memory usage.

NOTE: the OAuth 2.0 Bridge may also need to know further information on the client, such as signature method to be used against OAuth 1.0 infrastructure, allowed Protected Resources and other details typically set up during client registration. All this information is actually handled by the OAuth 1.0 and should also be queried and cached by the bridge, along with the client_secret and redirect_uri, as explained above. Using the information received from the AA Portal {clientjd, redirect_uri) plus the client_secret, the OAuth 2.0 Bridge sends a standard OAuth 1.0 Request Token requests towards the OAuth 1 .0 Authorization Server. The server responds with the Request Token and associated secret. The OAuth 2.0 Bridge temporarily caches the received Request Token, and the secret, in association with the clientjd. The time for caching this token/secret should also be configurable, independently from the caching time for the clientjd. The OAuth 2.0 Bridge immediately responds the AA portal with the obtained Request Token. Now, in response for step 1 , the AA Portal indicates the user that it must authenticate. The user authenticates. If this process fails, the flow is blocked here. Otherwise, proceed with next steps. The user is asked for authorization for the application identified by clientjd. If included in step 1 , the AA Portal considers the scope parameter to inform the user of the access scope requested by the application (e.g. access only to some APIs or specific functionalities within APIs). If the user denies the authorization, the flow is blocked here. If the user grants the authorization, proceed with next steps. The AA Portal informs the OAuth 1 .0 Authorization Sever about the authorization provided by the end user, including the granted access scope. The OAuth 1.0 Authorization Server responds with the associated Authorization

Code. All this communication takes places through the OAuth 2.0 Bridge, which acts as a proxy or relay between the two entities. Since the client signaled the Implicit Grant flow, the AA portal now sends a message to the OAuth 2.0 Bridge to trigger the procedure to obtain an OAuth 1.0 Access Token. This message includes the clientjd, the Authorization Code and the Request Token.

13. In addition to the information received from the AA Portal, the OAuth 2.o Bridge gets the Request Token secret and the redirect_uri from its cache and it sends and OAuth 1.o Access Token request towards the OAuth 1.0 Authorization

Server. The OAuth 1.0 Authorization Server answers with the Access Token and associated secret.

14. The OAuth 2.0 Bridge may choose to generate a new value for OAuth 2.0 Access Token (i.e. a value different from the value received from the OAuth 1 .0 Authorization Server). Additionally, the bridge also generates further details for the OAuth 2.0 side, such as token type, expiration information and, in case the token type requires a secret on the OAuth 2.0 side (e.g. MAC tokens), it also includes the secret (e.g. as mac_key). All this information, in addition to the OAuth 1.0 Access Token details, is stored in the bridge's mapping table. 15. In response to 12, the OAuth 2.0 Bridge sends the Access Token details (value, expiration time, type, etc) back to the AA Portal.

16. Following the OAuth 2.0 standard Implicit Grant flow, the AA Portal sends the Access Token to the client via the user-agent. For further details on this procedure, please, refer to [2]. Accessing Protected Resources

The following diagram shows how the OAuth 2.0 Bridge makes it possible to access, via OAuth 2.0, protected resources exposed by OAuth 1.0 infrastructure.

1. As result from user activity, the client sends a request for a protected resource URL exposed by the OAuth 2.0 Bridge. This URL corresponds with the URL of a Protected Resource exposed by the OAuth 1.0 infrastructure.

2. If the OAuth 2.0 Bridge does not have the OAuth 2.0 Access Token details (value, secret, access scope and associated clientjd) in its mapping table, as stored from previous accesses, it queries that information from the OAuth 1 .0 Authorization Server. The OAuth 1.0 Authorization Server responds with the requested information (note this will only work if Token values are the same on both OAuth 1.0 and 2.0 ends; that is the reason for permanently storing Access Token details in the mapping tables whenever token values differ on both sides). If the Access Token details cannot be recovered from the OAuth 1.0 infrastructure, the request is rejected with the appropriate error code, following OAuth 2.0 specifications. Otherwise, proceed with the rest of the steps

The OAuth 2.0 Bridge checks that the OAuth 2.0 Access Token is still valid. If so, it also checks that the received request is correctly signed in accordance to the Access Token type being used. If any of these validations fails, the request is rejected with the appropriate error code, following OAuth 2.0 specifications. Otherwise, proceed with the rest of the steps.

If not already stored, the OAuth 2.0 Bridge adds the Access Token details (value, secret, access scope, etc) in its mapping table for later usages. When temporal caching is used, this step may be used to refresh the Access Token entry within the mapping table, in order to extend its expiration time. The details on this fully depend on the specific implementation.

The OAuth 2.0 Bridge needs the client_secret to correctly form the OAuth 1.0 request. Therefore, if the OAuth 2.0 Bridge does not have the client_secret in its cache (as stored from previous accesses), it queries that information from the OAuth 1.0 Authorization Server. The OAuth 1.0 Authorization Server responds with the requested information.

The OAuth 2.0 Bridge temporarily caches the clientjd for later usages. The time this information will be maintained in the cache should be reconfigurable, so that the performance can be optimized against memory usage.

NOTE: the OAuth 2.0 Bridge may also need to know further information on the client, such as signature method to be used against OAuth 1.0 infrastructure, allowed Protected Resources and other details typically set up during client registration. All this information is actually handled by the OAuth 1.0 and should also be queried and cached by the bridge, along with the client_secret, as explained above. Now, based on the received request, the OAuth 2.0 Bridge builds the corresponding OAuth 1 .0 request to consume the Protected Resource. Note this is done by reusing the request body and headers excluding only the OAuth information (usually contained in the Authorization header), which needs to be updated to correctly build the OAuth 1.0 request. This implies: o Based on the mapping table and the received OAuth 2.0 Access Token, get the Access Token to be used on the OAuth 1.0 side. o Resigning the request using the client_secret and one of the appropriate signing schemes, as configured for the client during registration phase (all this information has been consulted during previous steps of this flow).

After receiving the request, the OAuth 1 .0 Protected Resource responds and the bridge simply passes that response to the client, in response to step 1 .

8. If the request is rejected by the OAuth 1 .0 Protected Resource with an 401 Unauthorized response, that may imply that the Access Token was already expired or is invalid due to other reasons. To learn if the reason is that the Access Token is no longer valid, and in order to avoid storing non-valid

Access/Refresh Tokens, upon a 401 Unauthorized response, the bridge queries the Access Token details information from the OAuth 1.0 Authorization Server. In case the response indicates that the Access Token does not longer exist or is no longer valid, the Bridge will eliminate all the Access Token details from its mapping table. In the end, as it can be observed, the OAuth 1 .0 infrastructure is the final responsible for accepting or denying the access based on the Access Token and for managing these Access Tokens.

Refreshing an Access Token

The following flow explains how to refresh Access Token with the help of the OAuth 2.0 Bridge.

1. The Client wants to refresh an Access Token, so, following OAuth 2.0 standard procedures, it sends a Refresh Token request to the OAuth 2.0 Bridge. This request includes the grant type = refresh_token, the refresh token itself and further parameters (see [2] for more details). 2. If the OAuth 2.0 Bridge does not have the client_secret in its cache (as stored from previous accesses), it queries that information from the OAuth 1 .0 Authorization Server. The OAuth 1.0 Authorization Server responds with the requested information.

3. The OAuth 2.0 Bridge temporarily caches the client_secret for later usages. The time this information will be maintained in the cache should be reconfigurable, so that the performance can be optimized against memory usage.

4. The OAuth 2.0 Bridge authenticates the client and checks whether the Refresh Token is valid for that client d, according to the information stored in its mapping table. If not, the request received in step one is rejected with an appropriate error code (see [2]). Otherwise, proceed with next step. 5. The OAuth 2.0 Bridge generates a new OAuth 2.0 Access Token and associated details (expiration time, etc). It may also choose to generate a new Refresh token. The OAuth 2.0 Bridge updates the mapping table with this new information, without modifying the corresponding information for the OAuth 1 .0 side.

6. The OAuth 2.0 Bridge responds the client with the new Access Token and associated details, which may also include a new Refresh Token.

This invention is applicable for any enterprise already offering open APIs protected by OAuth 1 .0 and willing to evolve to support OAuth 2.0 while keeping backwards support for OAuth 1 .0. This is especially important for API environments or scenarios where a relevant amount of final applications are installed in final-user's devices, instead of network-side entities, since updating and re-installing these applications to support OAuth 2.0 seems an almost impossible task (updates must be done by individual developers and there are no automatic procedures for re- installation).

A significant example for the application of this invention is the Telco operators market, and especially the WAC initiative [7], where applications are typically installed in user's handsets. Within the WAC initiative different players are offering mature APIs protected by OAuth 1 .0 [5], while others are beginning to use the newer protocol version. In order to provide a homogeneous mechanism for developers to access the APIs of all the operators, evolving to OAuth 2.0 seems the best solution, but keeping support for already working and profitable OAuth 1 .0 applications. Further examples for potential applicability are Internet companies, such as Twitter [6], which are also offering OAuth 1.0 APIs reachable from different kinds of applications, in many cases installed in users' mobile handsets or desktop devices. Advantages of the Invention

The basic idea of re-using existing OAuth 1.o infrastructure when evolving to OAuth 2.0 provides different benefits:

Cost reduction: as it is not necessary to build a complete OAuth 2.0 infrastructure, but only the OAuth 2.0 Bridge on top of it. - Faster OAuth 2.0 adoption: not only development effort is lower, but also test and deployment-related activities are simplified, since work is focused on an individual entity on top of an already working infrastructure.

Simpler provisioning and operation: the OAuth 1 .0 infrastructure remains as the main responsible for handling applications, token, user information and other system information. On the other hand, the OAuth 2.0 Bridge does not need to be provisioned with this information or to take the responsibility on these processes; it simply queries the OAuth 1.0 infrastructure and behaves accordingly to adapt between both protocols versions. As result, existing provision and operation processes are kept unmodified, avoiding the complexity of handling two parallel systems.

The present invention allows to efficiently providing support for both protocol versions, thus, keeping "legacy" applications working and giving developers broader options to build applications.

ACRONYMS

AA Authentication & Authorization API Application Program Interface HTTP Hypertext Transfer Protocol REST Representational State Transfer SOAP Simple Object Access Protocol URL Uniform Resource Locator

REFERENCES

[1] OAuth 1.0, http://tools.ietf.org/html/rfc5849

[2] OAuth 2.0. http://tools.ietf.org/html/draft-ietf-oauth-v2-22

[3] The OAuth 2.0 Protocol: Bearer Tokens, http://tools.ietf.org/html/draft-ietf-oauth-v2- bearer-08

[4] HTTP Authentication: MAC Access Authentication, http ://tools . ietf. org/htm l/d raft- ietf-oauth-v2-http-mac-00

[5] BlueVia developers OAuth guides, https://bluevia.com/en/knowledge/APIs.API- Guides.OAuth

[6] Twitter developers information, http://dev.twitter.com/pages/auth

[7] WAC - Wholesale Application Community, http://www.wacapps.net

[8] Roy Thomas Fielding, "REpresentational State Transfer (REST)", http://www.ics.uci.edu/~fielding/pubs/dissertation/rest arch style.htm

Claims

\ - A method for providing access to protected resources via an OAuth protocol, comprising providing access to protected resources to an application of a computing device through an OAuth 1 .0 infrastructure;

wherein the method is characterised in that said application supports OAuth 2.0 protocol, and in that the method comprises providing said access to protected resources through an OAuth 1.0 infrastructure to said application supporting OAuth 2.0 protocol by means of an intermediary entity adapting OAuth 2.0 protocol to OAuth 1.0 protocol, and vice versa.

2.- The method of claim 1 , comprising providing said access to said protected resources to said application supporting OAuth 2.0 protocol without modifying said OAuth 1 .0 infrastructure.

3.- The method of claim 2, comprising not modifying Authorization and Resource Servers of said OAuth 1.0 infrastructure.

4.- The method of claim 1 , wherein said intermediary entity for performing said adapting between said protocols is a bridge.

5. - The method of claim 4, wherein said bridge is perceived as an OAuth 2.0 infrastructure by said application supporting OAuth 2.0 protocol..

6. - The method of claim 4, wherein said bridge works on top of said OAuth 1.0 infrastructure.

7. - The method of claim 1 , comprising keeping supporting said applications using OAuth 1 .0 protocol.

8. - The method of claim 4, wherein said bridge further comprises:

a) intermediating and adapting flows between said OAuth 2.0 and said OAuth 1 .0 protocols;

b) translating syntax between said OAuth 2.0 and said OAuth 1 .0 protocols; c) validating OAuth 2.0 requests from said clients using said application supporting OAuth 2.0 protocol;

d) configuring and signing as OAuth 1 .0 requests such OAuth 2.0 requests coming from the clients using said application supporting OAuth 1 .0 protocol;

e) mapping Access Tokens between said OAuth 2.0 and said OAuth 1.0 protocols;

f) providing to said OAuth 2.0 protocol, comprising an authorization endpoint, a frontend such a web page interacting with the bridge which in turn interacts with said Authorization Server from said OAuth 1.0 infrastructure; and g) giving access to said protected resources from said OAuth 1.0 infrastructure from a URL exposed by said bridge, protected by said OAuth 2.0 protocol.

9. - The method of claim 8, wherein said step e) comprises storing token values at least for a period of time, if said token values are the same between both of said OAuth 2.0 and said OAuth 1 .0 protocols.

10. - The method of claim 9, wherein said at least period of time is a permanent period of time.

1 1. - The method of claim 8, wherein said URL exposed by said bridge corresponds with a URL of said protected resources from said OAuth 1.0 infrastructure.

12.- The method of claim 8, wherein the OAuth 2.0 intermediated and adapted flows are an Authorization Code and an Implicit Grant.

13. - The method of claim 8, wherein the bridge issues an OAuth 2.0 Refresh Token to said application supporting OAuth 2.0.

14. - The method of claim 13, wherein the bridge provides the OAuth 2.0 token refresh functionality, generating a new OAuth 2.0 Access Token and maintaining the mapping of Access Tokens between said OAuth 2.0 and said OAuth 1 .0 protocols.

15. - A system for providing access to protected resources via an OAuth protocol, said system comprising a OAuth 1.0 infrastructure providing said access to said protected resources and a computing device with an application supported by OAuth protocol, for accessing said protected resources, wherein said system is characterized in that said application supports OAuth 2.0 protocol; and in that the system further comprises an intermediary entity arranged between said computing device and said OAuth 1 .0 infrastructure and configured for providing to said application of said computing device said access to said protected resources by adapting OAuth 2.0 protocol to OAuth 1.0 protocol, and vice versa.

16. - The system of claim 15, wherein said system implementing a method according to any of the previous claims.