How to use OpenID Connect for authentication

To ensure only approved parties access business-critical data, developers must guarantee login security when building an application, whether it be a single-page application, server-side web application, native mobile app, API or microservice.

OpenID Connect has become the de facto protocol to authenticate users between applications and external identity providers (IdPs).

Prabath Siriwardena, OpenID Connect in Action author and identity and access management (IAM) evangelist, explained he wrote his book because "OpenID Connect is the most popular federated standard built on top of OAuth 2.0. The web has good resources on it; however, a single resource that explains multiple aspects of OpenID Connect is hard to find."

In this interview, Siriwardena explains who should read the book, why OpenID Connect became so popular and how to handle connecting multiple IdPs to applications.

Check out an excerpt of Chapter 3 of OpenID Connect in Action on how to use OpenID Connect with single-page applications.

Editor's note: The following interview has been edited for length and conciseness.

Who should read OpenID Connect in Action?

Learn more about OpenID
Connect in Action here.

Prabath Siriwardena: The book is mostly for developers building applications. Top industry talks focus on how to integrate OpenID Connect with single-page apps or traditional server-side apps. I wanted to include how to integrate with native mobile apps and browserless applications, such as applications running on a smart TV. You need hands-on development experience, which is why this book provides a lot of examples. Others who may benefit from my book include people who make architectural decisions.

What problem does OpenID Connect solve?

Siriwardena: OpenID Connect introduces two main things. One is it defines a schema for an ID token, such as for the attributes and the rules for processing them. The second is about how you transport this ID token from one place to another. When you use OpenID Connect for login, both aspects are used together.

If there's no OpenID Connect, the key problem comes when logging in to a website. A given person may have hundreds of logins across different applications. Maybe some people reuse their credentials, which can be a major security issue. It's a nightmare to maintain each credential. You also have your personal information like your first name, last name and mobile number saved to all these applications. And maybe you can't update the account info or forget to, so you end up having stale data.

To fix this problem, have one clustered IdP to maintain your identity. All the applications rely on that IdP to know about you. That's where the identity federation concept came in. Microsoft was the first on the web at a large scale with Passport. Microsoft acted as the passport server, which third parties knew they could rely on for login. However, Passport wasn't popular, largely because it was Microsoft and centralized.

OpenID is totally different. But it didn't address key use cases, such as in the enterprise. It is good for logging in to a community site or a blog and then writing a comment. But, at the enterprise level, there are more strict security requirements. For business use cases, OpenID doesn't address how to federate between multiple IdPs.

To fix this issue, OpenID Connect came out, and developers built the identity layer on top of OAuth 2.0. OpenID Connect standard is its own way of communicating. Unfortunately, it means OpenID and OpenID Connect are two incompatible standards. However, they both aim to solve the same high-level issue. That said, OpenID is dead, so if someone today uses the term, they likely mean OpenID Connect.

Security Assertion Markup Language (SAML) was the most popular in the mid-2000s. Why is that, and why has OpenID Connect surpassed it?

Siriwardena: SAML came out around 2005 and is purely XML-based. The popularity of XML started to fade around 2010 and 2011 when people began to favor JSON over XML because it was more lightweight. Mobile apps, IoT devices and single-page apps also started coming into use. XML is a little too heavyweight for those applications. The natural choice is JSON. From there, people wanted a standard that was small and lightweight. This is where OpenID came in.

OpenID was good for most community-based mobile applications but not for enterprise ones. OpenID Connect was built on top of OAuth 2.0 to solve that. More than that, it's evolving to have a long life; it has its own OpenID Connect Foundation and also the IETF [Internet Engineering Task Force] Working Group for OAuth. It basically addresses most modern use cases.

In OpenID Connect in Action, you address how to federate identities with multiple IdPs. How can one application connect with multiple IdPs?

Siriwardena: If you're building an application, you build on top of OpenID Connect. You trust one IdP, so whenever you want to authenticate a user, you redirect to that specific IdP. The one trusted IdP can then outbound federation to that user's own IdP. Doing it this way means, even if you want to introduce a new IdP or new protocol, you don't need to make any changes in your app.

Use a connector to write to an IdP. For example, use an OpenID provider as your IdP, which your app will always go through. From there, it will federate the user to Google, Twitter, your own enterprise IdP, etc. That response is taken care of by your IdP, which is also an identity broker. Implementing the login for users is becoming much easier because there are so many SDKs available in different languages. When you integrate OpenID Connect, a lot of companies want to connect with multiple identity providers with any of their SaaS apps. At the very least, apps need to be able to connect to social IdPs, but when including businesses, many have their own IdPs. They want to bring in users from their own IdPs. For example, take Slack or Stack Overflow -- almost all those sites rely on multiple IdPs.

Lastly, relying on just one provider isn't great, especially if you used a social login. I've seen times where this affects companies and users. Say you rely on Facebook Login; there are times where countries have banned access to the social media site. When banned, that social login won't work. It's always better to have multiple IdPs.

What are some common OpenID Connect threats and vulnerabilities?

Siriwardena: OpenID Connect is based on OAuth 2.0, which is a framework. This means you have multiple options, and you need to pick the best one for you. Once you make that decision, you need to worry about what's best in terms of security. I can't recall any times threats or vulnerabilities were due to OpenID Connect specification. Rather, they are introduced through poor implementation. I'm going to address this in Chapter 10 [Editor's note: We read an early access copy that didn't have Chapter 10 finished yet].

What kind of implementation vulnerabilities get introduced?

Siriwardena: I can give one good example. When you are using OAuth 2.0, it has a parameter called state parameter, which is an optional parameter. OpenID Connect has the same parameter. The state parameter is designed to avoid any cross-site request forgery attacks. While optional, it's recommended you send this parameter to the IdP so it can send the same value back. Then, before redirecting, you need to put that state variable into the browser's memory, whether as a cookie, saved in the local storage or in the session storage. Once you get back the response from the IdP, check whether it's the same value saved in the browser. If developers ignore doing this, they make their application possibly vulnerable to cross-site request forgery attacks.

Additionally, OAuth 2.0 introduced a new standard called PKCE [Proof Key for Code Exchange] that will prevent someone stealing your authorization code for mobile apps. It's widely used for web apps, single-page apps and more. It is recommended that developers support PKCE; however, PKCE is defined in a different RFC [request for comments]. The OAuth IETF Working Group is designing the OAuth 2.1 standard. OAuth 2.1 tries to address some of these vague and differentiating aspects of the OAuth 2.0 spec. This would reduce leaving decisions up to developers about whether to use it. PKCE is part of OAuth 2.1 itself, which wasn't the case for 2.0.

Beyond your book, what should a developer read to fully understand how to use OpenID Connect?

Siriwardena: What isn't covered in my book is taking this ID token and using it in the Kubernetes or Microsoft microservices ecosystem to secure the communication channel between services. In the microservices world, when you build cloud-native applications, there's another standard called SPIFFE [Secure Production Identity Framework for Everyone]. It uses the ID token defined by OpenID Connect to transport attributes from one place to another place. That's another important aspect. Developers are becoming more creative in using parts of OpenID Connect in different areas, even though that may not be its original intention.

About the author
Prabath Siriwardena is a member of technical staff for identity at DevRev. He is a developer, architect and evangelist with more than 18 years of industry experience designing and building critical IAM infrastructure for global enterprises, including many Fortune 100/500 companies. From 2007 to 2021, he led the development, architecture and strategy of the open source WSO2 Identity Server. As an evangelist, Siriwardena has published eight books, including OpenID Connect in Action (Manning), Microservices Security in Action (Manning), Advanced API Security (Apress) and Microservices for the Enterprise (Apress). Three of his books were translated into Korean, and one is being translated into Chinese. He blogs on various topics, including blockchain, Revised Payment Services Directive, GDPR, IAM and microservices security.