OpenID Connect, an identity layer on top OAuth, is one of the most important ways that access authorization and information is passed between two parties online. The OAuth2 protocol decides how a client receives a token from a consenting user and then uses that token on an API call.
Paul Madsen of Ping Identity argues that even though OAuth2 passes identity by way of that token’s permissions, the protocol lacks in that it does not withold useful user information. By layering OpenID Connect on top of OAuth2, the identity semantic comes into play and OAuth2 becomes identity aware, enabling things like single sign-on and personal profile information sharing. Watch Paul’s full talk below, or read on for key points.
OpenID Connect Key Identity Extensions:
- UserInfo Endpoint: The OAuth protected endpoint that provides user identity attributes, which limits registration form drop-off.
- ID Tokens: A structured, secure, signed information object that carries information about the user in question, like when they authenticated and how.
For an in-depth overview of OpenID Connect & OAuth check out: API Security: Deep Dive into OAuth and OpenID Connect
If widely adopted, OpenID Connect could transform identity control by enabling single sign-on, increasing information security, and helping to manage identity throughout the Internet of Things. Within this post we’ll dive into these three use cases on using OpenID Connect to securely manage user identity.
1: How OpenID Connect Enables Native SSO
OpenID Connect enables native single sign-on, usually referred to as Native SSO. As native apps continue to grow in popularity due to their ease of use and ease of distribution, there comes a greater demand for default OAuth in native environments. But the burden of managing authentication throughout a sea of various native apps falls on the end user, who must know which login is for which app, which needs to be re-authenticated, among other nuisances.
Forecasts show an increase in native app usage within the foreseeable future. In 2014, 86 percent of time spent on smartphones was spent within native apps, not web browsers. One way to get an edge in this increasingly crowded market is to increase usability with a single sign-on for multiple apps published by the same owner. This can be accomplished using OpenID Connect paired with OAuth.
The process involves the implementation of an Authentication Agent (AZA) which is either an agent installed on the device’s operating system or is it’s own separate mobile app. The mobile device user authorizes the AZA agent to retrieve tokens automatically from other native mobile apps that it’s authorized to use.
This case has an obvious appeal for businesses to enable and control SSO access to certain enterprise-grade applications, for both web and native apps, as well as for bundles of B2C apps that were created by the same brand that wants to give users easy access to them all.
The next step is establishing and standardizing the protocols under which this Native SSO can be permitted and tokens can be shared. The OpenID Foundation currently is collaborating on developing the specifications for native app SSO via OpenID Connect 1.0.
2: How to Use OpenID Connect to Enable Mobile Information Management and BYOD
Major security breaches have unfortunately been omnipresent in recent news. Various security management strategies are being employed to avoid these breaches with a determined focus on offering enterprises the confidence that their employees can use any mobile to access sensitive business apps while still having a standard of security, irrespective of mobile device in this bring-your-own-device (BYOD) world. Strategies include:
- mobile device management (MDM) aims to protect the whole device, regardless if it’s used for both business and pleasure. When applied to BYOD, privacy and property rights are then called into question.
- mobile application management (MAM) goes granular, with enterprise IT departments focusing just on securing business apps, compartmentalizing data and apps.
- mobile information management (MIM) then acts as the next step in this granularity. The enterprise imposes its management policy directly on the data itself. Business data is wrapped with security mechanisms and policy that constrain and determine how that data can be used.
MIM is key management. Using MIM, before data is passed to the device, it is encrypted with a corresponding key and a policy that encompasses how the data is passed down as well as how the encryption key is bound to the data. Decryption keys are then released only under strict conditions— the right user with the right key using the right app.
Madsen argues that OpenID Connect is significant to that key distribution model, via ID token and a user info API, as it follows an OpenID Connect flow with key distribution steps layered on top of it. The app itself doesn’t have a decryption key but it can use its access token to send its license back up to the key distribution server. That distribution server can from there determine who the user is, in what context, and under what licensed circumstance should a key be released. When approved, it hands back a key along with a license that constrains what can be done with the authorized data.
There’s no doubt that Mobile Network Operators (MNOs) are becoming increasingly aware of how OpenID Connect interacts with identity services currently being used online, including payments and log-ins. The widespread assumption is that OpenID Connect can mitigate pain points within existing services by offering a public key encryption-based authentication framework. This takes the burden of identity verification from the hands of the average user and puts it into the hands of expert service providers.
Of course, applying MIM using OpenID Connect is theoretical, and has not yet been proven. However, if the one-two punch of OpenID Connect and mobile information management (MIM) is widely adopted, it is assumed that it could increase the security of the entire Internet dramatically.
3: How OpenID Connect Enables the Internet of Things
Just as identity verification and authentication are priority topics for MNOs, these themes similarly must extend to the rapidly expanding world of the Internet of Things (IoT). As the number of IoT services increase, so will the number of passwords as mechanisms for sharing and trusting identities. “The importance of interoperability amongst identity solutions is that it will enable individuals to choose between and manage multiple different interoperable credentials,” said chief domain architect at BT Charles Gibbons.
According to Madsen, the Internet of Things (IoT) really assumes the Identity of Things because all these Things will be operating on our behalf, managing our data. There is a definite need to distinguish among different connected Things and their identities, as well as a need for a way to authenticate how these Things will collect data.
Via OpenID Connect, a Thing can obtain a token to use in an API call. The user is actively involved in the issuing of that token, and has the power to impose policies as to when that token can be used and how his or her data is shared.
Because OpenID Connect standardizes mechanisms by which users can control the sharing of the identity that they use, Madsen believes OpenID Connect will become a critical asset in the further development of usable, personalized, and secure IoT applications.