Methods, systems, and computer readable media for bridging user authentication, authorization, and access between web-based and telecom domains

TECHNICAL FIELD

0001The subject matter described herein relates to authentication and authorization pertaining to applications. More specifically, the subject matter relates to methods, systems, and computer readable media for bridging user authentication, authorization, and access across web-based and telecom domains.

BACKGROUND

0002Modern telecommunications networks offer users a vast array of options for connecting and interacting with one another. In addition to choices provided by telecommunications providers themselves, users can now utilize a variety of independently developed products and services that run “on top” of the infrastructure maintained by the telecommunications industry. These independently developed products and services are commonly referred to as over-the-top (OTT) services because these services are not developed with a specific telecommunications provider's network in mind, but rather are designed to interconnect users via a provider-independent platform.

0003With the proliferation of smartphone, social networks, OTT applications and self-serve application stores, users are increasingly creating their own customized bundles of applications, made up of applications from the telecom, enterprise and Internet domains. Within this disjointed application model, user identification, authentication and authorization has become a difficult management problem, forcing users to manage a large number of individual usernames and passwords, and having to log in multiple times each day, as they invoke different applications. Furthermore, they have to enter their personal information and manage this across all of the application domains that they access.

0004To address these issues, many of the large OTT sites and social networks have implemented delegated authorization mechanisms, which allow a user to login once to an OTT property, and then to use this login as a single-sign-on mechanism to other applications, and for authorizing other applications to access their personal data. This provides improved user experience for end users, and encourages them to remain anchored and active within the OTT community. These evolving mechanisms present a real problem for the telecom operators, since it encourages users to anchor their application experience in the OTT domains and social networks, which creates a barrier for operators when introducing new telecom hosted applications.

0005Accordingly, a need exists for methods, systems, and computer readable media for bridging user authentication, authorization, and access across internet and telecom domains.

SUMMARY

0006The subject matter described herein includes methods, systems, and computer readable media for bridging user authentication, authorization, and access across internet and telecom domains. According to one embodiment, a method includes issuing, to an application hosted in a web-based network, an access token associated with a user identifier subscribed to a telecommunications network, wherein the access token is issued in response to receiving telecommunications network credentials from a client device associated with the user identifier and receiving, at an over the top (OTT) proxy element in the telecommunications network from the application, the access token for requesting user data associated with the client device to be used to access the application. The method further includes retrieving the user data if the access token is valid a telecommunications network context condition is met and providing the user data to the application, wherein access to the application by the client device is based on the user data.

0007According to another embodiment of the present subject matter, a system includes an application server residing in a web-based network that is configured to host an application and to provide an access token associated with a user identifier subscribed to a telecommunications network, wherein the access token is initially received by the application in response to a client device associated with the user identifier providing telecommunications network login credentials to an OTT proxy element. The system further includes an OTT proxy element that resides in a telecommunications network and is configured to receive the access token from the application server, to retrieve the user data if the access token is valid and a telecommunications network context condition is met, and to provide the user data to the application, wherein access to the application by the client device is based on the user data.

0008The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein may be implemented in software executed by one or more processors. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

0009As used herein, the term “node” refers to a physical computing platform including one or more processors and memory.

0010As used herein, the terms “function” or “module” refer to software in combination with hardware (such as a processor) and/or firmware for implementing features described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

0011The subject matter described herein will now be explained with reference to the accompanying drawings of which:

0012<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an exemplary network for bridging user authentication, authorization, and access across Internet and telecom domains according to an embodiment of the subject matter described herein;

0013<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart illustrating an exemplary process for bridging user authentication, authorization, and access across internet and telecom domains according to an embodiment of the subject matter described herein;

0014<figref idref="DRAWINGS">FIG. 3</figref> is a message flow diagram illustrating a request for an access token to an OTT proxy element according to an embodiment of the subject matter described herein; and

0015<figref idref="DRAWINGS">FIG. 4</figref> is a message flow diagram illustrating a single sign on (SSO) procedure where a user is SIP registered according to an embodiment of the subject matter described herein;

0016<figref idref="DRAWINGS">FIG. 5</figref> is a message flow diagram illustrating a single sign on (SSO) procedure where a user is not SIP registered according to an embodiment of the subject matter described herein; and

0017<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating an exemplary token architecture according to an embodiment of the subject matter described herein.

DETAILED DESCRIPTION

0018Methods, systems, and computer readable media for bridging user authentication, authorization, and access between web-based and telecom domains are provided. According to one aspect, the present subject matter described herein may include a system that enables telecommunications identities (e.g., IMS/SIP) and credentials to be used in an implicit manner to authenticate web users in a single sign on (SSO) operation. The system may also allow user profile, context, ad targeting data, and the like to be authorized and shared with a web based application according to authorization policies. In one embodiment, the present subject matter utilizes a mechanism to integrate token based authorization, such as oAuth 2.0, into the IMS identity architecture. Similarly, the present subject matter may employ a mechanism to extend implicit user authorization to other applications and utilize a dynamic token status to allow authorization status to reflect user context, policy rules, and registration state. Although the following disclosure described the use of oAuth 2.0 tokens, any other token based authentication scheme may be used without departing from the present subject matter.

0019<figref idref="DRAWINGS">FIG. 1</figref> depicts an exemplary system <b>100</b> that comprises an over-the-top (OTT) proxy element <b>102</b> (e.g., an OTT proxy gateway, an OTT proxy server, etc.) that resides at the edge of a telecommunications (i.e., telecom) network <b>110</b>, such as an IP multimedia subsystem (IMS) and/or session initiation protocol (SIP) network. In one embodiment, telecommunications network <b>110</b> may include a token manager <b>116</b>, a user profile server <b>114</b>, and a registrar server <b>112</b>. OTT proxy element <b>102</b> may also be communicatively connected to an ecosystem application server (EAS) <b>106</b> residing in a web-based Internet network. EAS <b>106</b> may also be connected to a token storage server or database <b>108</b>. System <b>100</b> may further include at least one client device <b>104</b> which may be used by a telecom subscriber to access applications residing in the web-based internet network. Although only one EAS <b>120</b> is shown in <figref idref="DRAWINGS">FIG. 1</figref>, additional application servers may be communicatively coupled to OTA proxy element <b>102</b> without departing from the scope of the present subject matter.

0020In one embodiment, client device <b>104</b> may include any mobile client device, such as a smartphone, a cellular phone, and a personal digital assistant device, that can access a SIP based telecommunications network. In another embodiment, client device <b>104</b> may include a fixed client device, such as a personal computer (PC) or an Internet protocol television (IPTV), that utilizes fixed access (e.g., DSL) to access an application. For example, client device <b>104</b> may also include any device that can register with an IMS/SIP network. In one embodiment, client device <b>104</b> may be configured to use an active registration state (e.g., an active SIP registration state) to identify, authenticate and authorize itself within web and internet based applications. For example, client device <b>104</b> may be configured to utilize an access token to implicitly log into an ecosystem partner application using associated SIP/IMS login information and state. In one embodiment, client device <b>104</b> may be provisioned with a non-telecom client application, such as a local web browser. Although the active registration state is described herein as an active SIP registration state, registration states established in other protocols (e.g., a subscriber identification module (SIM) protocol, a radius protocol, a Diameter protocol, a packet data protocol (PDP) context protocol, an extensible messaging and presence protocol (XMPP), etc.) may be utilized without departing from the scope of the present subject matter. In one embodiment, the present subject matter may apply to other forms of registered services, such as an extensible mapping and presence protocol (XMPP) or proprietary systems, such as Skype and the like.

0021In one embodiment, EAS <b>106</b> may include any type of network node, server, or element that resides in the IP network. EAS <b>106</b> may be configured to host one or more applications, such as application <b>120</b>. For example, application <b>120</b> may include a web-based application that may require a username and password to establish a log-in session. Although the following disclosure describes application <b>120</b> as a web application or web-based application, other applications (e.g., enterprise based applications or mobile device applications) may be utilized without departing from the scope of the present subject matter. EAS <b>106</b> may also have access to a token storage entity <b>108</b>. In one embodiment, token storage entity <b>108</b> may include any network element, server, or database residing in the web-based portion of system <b>100</b> that is configured to provide user authorization policies and token resolution. For example, token storage entity <b>108</b> may maintain and manage saved access tokens issued by OTT proxy element <b>102</b>. Notably, access tokens stored in token storage entity <b>108</b> may be issued by and used to gain access to OTT proxy element <b>102</b>.

0022In one embodiment, OTT proxy element <b>102</b> may include any network element residing in telecommunications network <b>110</b> that is configured to provide a secure bridge between an IMS/SIP network and a web based network. For example, OTT proxy element <b>102</b> may utilize a management module <b>122</b> to perform a number of functions that coordinate the interactions between a telecommunications network and one or more Internet protocol networks. For example, management module may provide security functions for traffic entering into telecommunications network <b>110</b> from the IP network. Management module <b>122</b> in OTT proxy element <b>102</b> may also be configured to receive web-based application access requests from ecosystem application servers. Notably, management module <b>122</b> may manage a plurality of web-based application programming interfaces (APIs) (e.g., HTTP related) that handle incoming requests from web-based applications in the IP network(s). Management module <b>122</b> may also coordinate the APIs provisioned on OTT proxy element <b>102</b> to map incoming IP-based requests into an appropriate telecommunications protocol and facilitate the interaction with the correct network component in the telecommunications network <b>110</b>. For example, management module <b>122</b> may interact with the voice network by mapping between VoIP voice call protocols and telecom voice call protocols. Management module <b>122</b> in OTT proxy element <b>102</b> may also manage external APIs that provide a particular quality of service (QoS) to web-based application traffic. In one embodiment, OTT proxy <b>102</b> presents and manages REST APIs to external applications (e.g., application <b>120</b>).

0023In one embodiment, OTT proxy element <b>102</b> may be configured to facilitate the assignment of access tokens. For example, a telecom subscriber associated with client device <b>104</b> may attempt to first access a web-based application <b>120</b> hosted in an IP network. In instances where client device <b>104</b> cannot be authenticated (e.g., is not logged into or registered) by application <b>120</b>, application <b>120</b> may be configured to redirect the client device <b>104</b> to a telecom provider's OTT proxy element <b>102</b>. Client device <b>104</b> may then be used to provide its telecommunications based credentials (i.e., not IP based credentials) to OTT proxy element <b>102</b>. In one embodiment, client device <b>104</b> provides a SIP user address and a related password to OTT proxy element <b>102</b>. In response, OTT proxy element <b>102</b> may forward these user credentials to a registrar server <b>112</b> to determine if client device has an active SIP registration state and to a user profile server <b>114</b> to determine the access policies associated with client device <b>104</b>. In one embodiment, user profile server <b>114</b> may include any network element residing in telecommunications network <b>110</b> that is configured to provide identity authorization service. For example, user profile server <b>114</b> may maintain and manage identity mappings (e.g., SIP to OTT property), persona identification, and the addition of passwords to IMS profiles. In one embodiment, registrar server <b>112</b> may include any network element residing in telecommunications network <b>110</b> that is configured to provide user context service. For example, registrar server <b>112</b> may maintain and manage persona identification and real-time registration state (e.g., IMS registration and/or SIP registration) of client device <b>104</b>.

0024Once authenticated by registrar server <b>112</b>, a token manager <b>116</b> may generate an access token that includes access policies associated with the authenticated client device and at least one application. In one embodiment, token manager <b>116</b> may include any network element residing in telecommunications network <b>110</b> that is configured to provide user authorization policies and token resolution. For example, token manager <b>116</b> may maintain and manage the assignment of privileges (i.e., authorization policies) to tokens based on the application, user, persona, and the like. Token manager <b>116</b> may also be used to generate tokens and map tokens to user authorization policies. An exemplary access token may include security information for a log-in session, such as a user's identification, a user's groups, and a user's privileges (e.g., access token policies). In one embodiment, the user's identification may include a SIP public identifier, which may comprise of one or more user attributes such as, an explicit login password, user preferences, usage analytics (e.g., advertisement targeting data), personalization data, charging data (e.g., credit card number), previous visit history, friend/buddy data, and an access grant list (e.g., application identifier, expiry, permissions and policies, etc.).

0025In one embodiment, the generated token may include access policies that are associated with the authentication session related to the web-based application <b>120</b> that the client device <b>104</b> is attempting to access. Thus, a telecom provider may utilize OTT proxy element <b>102</b> to control the application's access to the telecom network as well as access to profile data and context data associated with client device <b>104</b>. In one embodiment, the user's context data includes state information related to the user, such as presence information, location information, registration information, and roaming state. Similarly, a user's profile data may include profile authorization rules that are based on day of the week, time of day, active persona, user device type, current access network, and the like.

0026After the access token is generated, OTT proxy element <b>102</b> redirects client device <b>104</b> back to application <b>120</b>. OTT proxy element <b>102</b> also provides the application with the access token. In one embodiment, access token exchanges are communicated via a secure transport layer, such as HTTPS (SSL), in order to protect token integrity. Similarly, oAuth 2.0 token exchange may be used to protect the user credentials in the telecommunications network.

0027Upon receiving the access token, application <b>120</b> authenticates client device <b>104</b> and provides client device <b>104</b> access to the application web site. Notably, the user of client device <b>104</b> does not need to obtain a user identifier or establish a password with the IP based application <b>120</b>. The application <b>120</b> may also store the access token in token storage entity <b>108</b> (e.g., a dedicated server or database) for later use.

0028In the event client device <b>104</b> makes a subsequent request to access the IP based application <b>120</b>, application <b>120</b> identifies the client device <b>104</b> and accesses token storage <b>108</b> in order to retrieve the related access token. In one embodiment, the application may identify client device <b>104</b> by detecting a cookie user identifier in client device <b>104</b>. Application <b>120</b> may also utilize the cookie user identifier to retrieve the correct access token in token storage <b>108</b>. The application may then pass the retrieved access token to OTT proxy element <b>102</b>, which then retrieves user related data associated with client device <b>104</b>, such as the user's SIP public user identifier and token access policies. Prior to providing the user related data to application <b>120</b>, OTT proxy element <b>102</b> may also determine whether client device <b>104</b> is SIP registered and whether the token is valid by communicating with registrar server <b>112</b>. If client device <b>104</b> is SIP registered and the token is still valid, OTT proxy element <b>102</b> notifies the application that the user of client device <b>104</b> has been authenticated and provides the user profile and context data to application <b>120</b>. The profile and context data that application <b>120</b> is authorized to received is determined by the token policies contained within the access token. After receiving the user profile and context data, application <b>120</b> establishes a log-in session for client device <b>104</b> and utilizes the user profile and context data to customize the user's experience. Although the above example describes an embodiment based on IMS/SIP registration mechanisms, other stateful registration mechanisms such as packet data protocol (PDP) context establishment, PDP activation, AAA via radius/Diameter registration (e.g., via DSL), a subscriber identification module (SIM) protocol mechanism, an extensible messaging and presence protocol (XMPP) mechanism, a voice over IP application protocol mechanism (e.g., Skype), and presence server state, may be used without departing from the scope of the present subject matter.

0029<figref idref="DRAWINGS">FIG. 2</figref> depicts a flow chart that depicts a method <b>200</b> for media for bridging user authentication, authorization, and access between web-based and telecom domains. For example, method <b>200</b> discloses a single sign on and user authentication process that may be conducted in accordance with the present subject matter. In block <b>202</b>, a client device <b>104</b> accesses a web application <b>120</b> hosted by an EAS <b>106</b>. For example, client device <b>104</b> may access the web application <b>120</b> via an HTTP GET message. In one embodiment, EAS <b>106</b> resides in a web-based domain and client device <b>104</b> is associated with a user subscribed to a SIP-based telecommunications network <b>110</b>.

0030In block <b>204</b>, a determination as to whether an access token is available (if the client device is not logged into the application). For example, application <b>120</b> determines if an access token associated with the requesting client device <b>104</b> is available in token storage. If the access token is not available, method <b>200</b> proceeds to block <b>206</b> where application <b>120</b> redirects the client device <b>104</b> to OTT proxy element <b>102</b>. In one embodiment, application <b>120</b> uses a an HTTP <b>302</b> message to redirect client device <b>104</b> to OTT proxy element <b>102</b> and provide a client identifier and a return URL address associated with application <b>120</b>. A client application in client device <b>104</b> may contact OTT proxy <b>102</b> for authentication by providing the client identifier and an application identifier via an HTTP GET message.

0031In block <b>208</b>, a request for access to user profile/context data is received. In one embodiment, OTT proxy element <b>104</b> presents a web page to client device <b>104</b> requesting permission to allow application <b>120</b> to access login data associated with client device <b>104</b>. As used herein, profile data includes static information that may be provisioned and stored. Notably, profile data may includes data that remains static for long periods of time, such as a user name, an address, friend lists, phone numbers, app preferences, display format, and the like. Similarly, context data may include dynamic information that changes frequently, either changed directly by the user or changed due to user behavior or network/environmental conditions. Examples of context data that may be changed by the user include availability status (e.g. Busy, Please do not disturb), current profile photo and persona (e.g., a work profile vs. a home profile). Examples of context information that may change as a result of user behavior or network/environmental conditions may be presence state (e.g., user currently using the phone), user location, and time sensitive conditions. Notably, the present subject matter provides a secure and controlled way for applications to access both statically provisioned and dynamically provisioned user related data that is available within the operator's network.

0032In block <b>210</b>, the client device is redirected back to the web application. In one embodiment, after providing permission, client device <b>104</b> is redirected back to application <b>120</b> via the return URL address. OTT proxy element <b>102</b> also provides a unique authorization code to application <b>120</b>.

0033In block <b>212</b>, an access token is requested. In one embodiment, application <b>120</b> uses the authorization code and application identifier to request an access token from OTT proxy element <b>102</b>.

0034In block <b>214</b>, the application and authorization code are validated. In one embodiment, OTT proxy element <b>102</b> validates application <b>120</b> and the provided authorization code. Upon completing the validation process the OTT proxy element <b>102</b> provides an access token to the application. OTT proxy element <b>102</b> also retrieves the user's SIP login session data and POSTs the login session data to the application <b>120</b>.

0035Returning to block <b>204</b>, if is determined that an access token is available to application <b>120</b>, then method <b>200</b> proceeds to block <b>216</b>, where user profile/context data is requested from the OTT proxy element. In one embodiment, application <b>120</b> passes the access token to OTT proxy element <b>102</b> in an attempt to retrieve profile and context data associated with client device <b>104</b>.

0036In block <b>218</b>, the user profile/context data is obtained. In one embodiment, OTT proxy element <b>102</b> retrieves a SIP public user identifier and token access polices that are associated with client device <b>104</b>. OTT proxy element <b>102</b> may be configured to retain SIP public user identifier and token access polices if the access token is validated and a telecommunications network context condition is met. An exemplary telecommunications network context condition includes the determination that client device <b>104</b> having an active SIP registration. Other exemplary telecommunications network context conditions include an approved subscription state associated with the client device (e.g., permitting access if the user has not exceeded data usage limits) and the presence (e.g., geographical presence) of the client device <b>104</b> in the telecommunications network service area.

0037In block <b>220</b>, a determination is made as to whether the access token is expired. If the access token is expired and invalid, OTT proxy element <b>102</b> notifies application <b>120</b> of the expired token via an HTTP <b>401</b> unauthorized message and method <b>200</b> loops back to block <b>206</b> where the token granting sequence is initiated in order to obtain a new access token. If the access token is found to be valid, then method <b>200</b> continues to block <b>224</b> where a determination is made as to whether client device <b>104</b> has an active SIP registration. If the client device <b>104</b> is SIP registered, then method <b>200</b> continues to block <b>226</b> where the OTT proxy element <b>102</b> provides user profile/context data to application <b>120</b>. In one embodiment, OTT proxy element <b>102</b> sends a 200 OK message to application <b>120</b> to indicate that client device <b>104</b> is authenticated. OTT proxy element <b>102</b> also sends the SIP user profile and context data that the application is authorized to receive (per the policies indicated in the access token). Application <b>120</b> may then log in client device <b>104</b> (into application <b>120</b>) and uses the profile/context data to customize the user's experience within application <b>120</b>. In one embodiment, customization of the user experience may involve an application to record past user actions and activities related to that application. For example, a given application may store usage logs, recall past purchases on a commerce website, store a history of other people the user has communicated with, displaying the last screen/page, recording an eBook library list, and the like. Application <b>120</b> may also store user preferences (e.g., display preferences, preferred instant messaging tool, preferred notification mechanisms, etc.), user profile data (e.g., friend/contact lists, billing/credit card numbers, user display name, profile photos, electronic business cards, etc.), application specific data (e.g., current page in open eBooks, favorite shopping categories for commerce applications, etc.), and user context data (e.g., the user's current location). The present subject matter also allows different applications to have controlled access to different portions of a particular user's profile/context data, which the application may then use to customize that application for the user. For instance, a web site for a store (e.g. Wal-Mart) may use user location information context data and previous shopping behavior for the user to display relevant items which are on sale at local stores. A social network may use contact or call log data to suggest new friends within the social network. A communication app may use the preferred notification mechanism data when new calls/messages arrive.

0038Returning to block <b>224</b>, if it is determined that client device <b>104</b> is not currently SIP registered, then method <b>200</b> proceeds to block <b>228</b>, where an error message is sent to the web application. In one embodiment, OTT proxy element <b>102</b> returns a “User not Registered” error message to application <b>120</b>. In block <b>230</b>, client device is redirected to a login service. In one embodiment, application <b>120</b> redirects client device <b>104</b> to a login service hosted by OTT proxy element <b>102</b>. The user may be prompted to interact with the login service by providing a SIP user identifier and a password (i.e., conducting a SIP registration). In one embodiment, by providing a SIP user identifier and password, a user may activate the access token.

0039In block <b>232</b>, the client device is redirected to the application. In one embodiment, OTT proxy element <b>102</b> may redirect client device <b>104</b> to application <b>120</b> after the user is authenticated and their registration status as stored in registrar server <b>112</b> is changed to “web registered”. Specifically, OTT proxy element may redirect client device <b>104</b> to application <b>120</b>. Application <b>120</b> may then send an HTTP GET message with the access token to OTT proxy element to restart the single sign on process.

0040<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary messaging flow diagram that depicts a request for an access token from OTT proxy element <b>102</b>. In this example, a user associated with client device <b>104</b> is currently registered in the IMS/SIP network <b>110</b> and attempts to use an IMS/SIP login to access an ecosystem application hosted by EAS <b>106</b> in a web based domain. In one embodiment, client device <b>104</b> may send an HTTP GET message while browsing an ecosystem partner web/cloud application hosted by EAS <b>106</b>. Upon receiving the HTTP GET message, EAS <b>106</b> may determine that the user is not logged into the requested application. The application may then redirect client device <b>104</b> to OTT Proxy element <b>102</b> for authentication. In one embodiment, EAS <b>106</b> may send, to client device <b>104</b>, an HTTP <b>302</b> redirect message that includes both a client/application identifier and a return URL associated the hosted application. The client/application identifier and return URL are stored by OTT proxy element <b>102</b> for future use and reference. Client device <b>104</b> may then contact OTT proxy element <b>102</b> (e.g., via redirection by the application) and provide the client/application identifier via an HTTP GET message. In response, OTT proxy element <b>102</b> queries client device <b>104</b> for permission to allow the application on EAS <b>106</b> to access the user's IMS/SIP login data. In one embodiment, OTT proxy element <b>102</b> presents a web page that is displayed on client device <b>104</b> that asks the user via a 200 OK message to allow the accessed ecosystem application to access the client's IMS/SIP login data. After client device <b>104</b> provides permission, OTT proxy element <b>102</b> sends a message to client device <b>104</b> that redirects client device <b>104</b> to the application hosted at EAS <b>106</b>. For example, OTT proxy element <b>102</b> may send a redirection message that contains the return URL associated with the hosted application and a unique authorization code.

0041Upon receiving the redirection message, client device <b>104</b> uses the return URL to contact EAS <b>106</b> and provides the authorization code to the hosted application. The hosted application then uses the authorization code along with an application identifier and application secret (or any other confidential piece of information, such as a long stream of apparently random characters) to request an access token from OTT proxy server <b>102</b>. In one embodiment, a network operator (e.g., an authentication server) provides the application secret to one or more applications. The receiving application may then be configured to keep the application secret confidential (e.g., the application secret should not be made visible in any manner). In the event an application performs an authentication process, the application provides the application secret back to the authentication server. Thus, an additional layer of security to help ensure the application is recognized by the authentication server.

0042In response to the access token request, OTT proxy server <b>102</b> may validate the application (e.g., comparing the application identifier with the previously provided client/application identifier) and the authorization code and return an access token to the application at EAS <b>106</b>. OTT proxy element <b>102</b> may then retrieve the user's login session data and provides (e.g., POSTs) the user data to the application instance, using the client/application identifier to determine the application URL. In an alternate embodiment, a PULL operation may instead be initiated by the application. After client device <b>104</b> is granted access to the hosted application, the hosted application may store the access token for future use and access associated with client device <b>104</b>.

0043<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary messaging flow diagram that depicts a single sign on (SSO) operation involving OTT proxy element <b>102</b>. Although the following example describes tokens being used for controlled access to user profile and context data, tokens may also be applied to access other resources, such as APIs and specific data without departing from the present subject matter. In this example, a user is currently registered with the IMS/SIP network <b>110</b> and has also previously authorized and logged into an ecosystem application hosted by EAS <b>106</b>, which resulted in the application receiving an access token (e.g., an oAuth token) to the ecosystem application. In one embodiment, client device <b>104</b> is used to access an ecosystem partner application hosted by EAS <b>106</b> (e.g., device <b>104</b> issues an HTTP GET message to access partner application). In response, EAS <b>106</b> identifies the user and/or client device <b>104</b> (e.g., by accessing a user identifier cookie on client device <b>104</b>) and determines that the user is not currently logged into the requested application. EAS <b>106</b> may then use the user identifier to access token storage <b>108</b> to retrieve a previously issued access token associated with the user from token storage <b>108</b>. EAS <b>106</b> may then attempt to retrieve user data (e.g., SIP/IMS profile/context data) from OTT proxy element <b>102</b> by passing the access token to OTT proxy element <b>102</b>. Upon receiving the access token, OTT proxy element <b>102</b> may then access user profile server <b>114</b> and requests user data (e.g., a SIP public user identifier, token access policies, etc.) associated with the access token. OTT proxy element <b>102</b> may then receive information about the SIP user and determine whether or not the access token is still valid (i.e., has not expired). In one embodiment, the validity of an access token is based on context and policy decisions. OTT proxy element may then also determine whether or not client device <b>104</b> is still currently SIP registered.

0044If the access token is valid and the SIP registration is active, OTT proxy element <b>102</b> may return a 200 OK message to indicate that client device <b>104</b> has been authenticated. In one embodiment, OTT proxy element <b>102</b> may also include the profile and context data the application is authorized to receive (i.e., as indicated in the token policies). In response, an API associated with the partner application may use the access token to login the user and use the returned profile/context data in the access token to customize the user's experience.

0045<figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary messaging flow diagram that depicts a single sign on (SSO) operation involving OTT proxy element <b>102</b> in the event client device <b>104</b> is not SIP registered. In this example, client device <b>104</b> has previously registered with IMS/SIP network <b>110</b> and is also authorized and logged into an ecosystem application hosted by EAS <b>106</b>, which resulted in the application previously receiving an access token (e.g., an oAuth token). In one embodiment, the application accesses a browser cookie or unique identifier stored in a client application in client device <b>104</b>. In one embodiment, client device <b>104</b> is subsequently used to access an ecosystem partner application hosted by EAS <b>106</b> (e.g., via issuing an HTTP GET message). In response, the application identifies client device <b>104</b> (e.g., by recognizing a cookie user identifier) and determines that client device <b>104</b> is not currently logged into the requested application. EAS <b>120</b> may then retrieve an access token associated with the user from token storage <b>108</b>. EAS <b>120</b> may then attempt to retrieve user SPI/IMS profile/context data from OTT proxy element <b>102</b> by passing the access token to OTT proxy element <b>102</b>. Upon receiving the access token, OTT proxy element <b>102</b> may then access user profile server <b>114</b> and requests user data associated with the access token, such as a SIP public user identifier, token access policies, and the like. OTT proxy element <b>102</b> may then determine whether that client device <b>104</b> is not registered with IMS/SIP network <b>110</b>.

0046Upon determining that client device <b>104</b> is not SIP registered, OTT proxy element <b>102</b> may direct a “User not Registered” error message to application <b>120</b>. In response, application <b>120</b> may send a redirect message to client device <b>104</b>. Client device <b>104</b> may then be redirected to a login service supported by OTT proxy element <b>102</b>. In one embodiment, client device <b>104</b> is used to interact with the login service to SIP register by entering a SIP user identifier and password. Client device <b>104</b> is then authenticated and the SIP registration status is changed to “web registered”. OTT proxy element <b>102</b> may then send a redirect message to client device <b>104</b> which instructs client device <b>104</b> to contact the partner application, which may then reissue the HTTP GET message with the valid access token to OTT proxy element <b>102</b>.

0047<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram of an exemplary access token architecture. An access token is a mechanism which allows user profiles, context, ad targeting data and the like to be authorized and shared according to authorization policies, such as polices maintained at network PCRFs. Token <b>600</b> may be depicted as comprising at least four portions that include an

0048IMS/SIP public user identifier <b>602</b>, an application client identifier <b>604</b>, a policy identifier <b>606</b>, and an expiry timestamp <b>608</b>. In one embodiment, IMS/SIP public user identifier <b>602</b> may be made up of an OTT proxy user profile that includes user credentials and a list of active tokens associated with the user. IMS/SIP public user identifier <b>602</b> may also include an HSS profile and/or a user profile that each contains a service filtering policy and transparent data. Policy identifier <b>606</b> may contain an authorization policy that includes token validity rules, API restrictions, and SLA limits.

0049In one embodiment, policy identifier <b>606</b> may include a number of different customized usage policies attached to access token <b>600</b>. For example, policy identifier <b>606</b> may include fields that indicate the SIP registration status of the user, different roaming statuses (e.g., active vs. suspended) associated with different types of calling networks (e.g., home, roaming domestic, roaming international, etc.) utilized by the user, the API usage associated with the user (e.g., whether to allow or block instant messaging or presence notifications), and an API SLA associated with the user (e.g., whether a call should be allowed, throttled, or blocked depending on how may calls the user receives in an hour). For each of these fields, policy identifier <b>606</b> may also include an associated specific policy field. For example, if the user is not SIP registered, policy identifier <b>606</b> may prompt the user for login credentials. If the user is SIP registered, then policy identifier <b>606</b> may indicate an active status associated with the user. Similarly, if the client device associated with the user is in the home network or roaming domestically, then the policy associated with this particular token may indicated that roaming capabilities are activated. In contrast, if the client device is roaming internationally, the policy may indicate that roaming capabilities are suspended. Token <b>600</b> may also include API usage and API SLA policies associated with the client device. For example, the policy may indicate that the client device may receive an unlimited number of UM notifications, but may block all presence notifications.

0050In short, token <b>600</b> may include a usage policy that is customized for each particular client device. For example, customized SLA grades, customized authentication behaviors and customized authorization levels for different users and applications may be included in each particular token. In addition, modifications made to token <b>600</b> enables a network operator to dynamically change a user's authorization status to reflect user context, policy rules, and registration state.

0051It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.