Developing Secure Applications Part 2 OpenID Connect

Introduction
This article is part 2 of a four part series where we look at the issues around developing secure applications. In Part 1 we looked upon Securing applications with Secure Socket Layer, in this second part we will look at the OpenID Connect from the OpenID Foundation.

The source code for this article can be found here.

The OpenID Connect (OIDC) standard defines a inherently web-based decentralized protocol based on OAuth 2.0. We look in detail at OAuth2 in part 3 of this series.

As we outlined in the first part of this series there exist security vulnerabilities that can only be addressed with the use of an identity guarantee(certificate)  provided by a signed digital certificate from an authentic Certificate Authority.  Where digital certificates work to allow encrypted streams between applications most web Applications particularly social and commercial use individual personal identity and need to collect and exploit much more sensitive and individual user information.

There are many security issues that arise as a result of personal information becoming compromised and used for identity theft. We can see the extent and damage of this is by the ongoing and successful security attacks starting from 2011 on one prominent corporation and continuing today.

OpenID is an open standard sponsored by many of the big Social media players like Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows Web and mobile applications to simplify and consolidate security systems and user identity. OpenID improves security by allowing users to consolidate their digital identities in a single identity repository that plays a role similar to the Certificate Authority when an application seeks to authenticate a user.

OpenID allows user to be authenticated using a third-party services called identity providers or OpenID providers. Users can choose to use their preferred OpenID provider such as Facebook or Yahoo for example to log in to websites that accept the OpenID authentication scheme.

To provide this solution OpenID Connect uses what is known as a Federated identity.  A Federated identity brings together all the web identities a user has across several external applications like Facebook or Yahoo.

OpenID Connect is the latest version OpenID. OpenID Connect is a modern federation specification designed for mobile and resource constrained applications in low-bandwidth scenarios.

OpenID Connect allows you to implement an Identity Management System to verify a User attempting to authenticate based on that authentication being performed by a third party application providers or as we shall see in the article it can be our own intranet server.

Figure 1 OpenID Connect builds on OAuth

By building on OAuth2, OpenID Connect enables delegated access and federation of identity.

Referring to the figure 1 we can describe what is often described as the Openid dance, as it follows a series of steps which we briefly outline.

Step 1:  user registers and creates a federated identity with the Openid provider.

Step 2:  the user access our application to login and authenticate.

Step 3:  our application redirects the user to enter username and password at the Openid

Provider, which then confirms access to the user’s federated identity.

Step 4   our application is provided with a ‘identity token’ that we can use to retrieve information

About the user.

OpenID Connect extends OAuth2 with ID tokens. These are intended for our application. Unlike OAuth access tokens and refresh tokens that are opaque to the application. The OpenID identity token allows the application to know how and when the user authenticated and with the OAuth ‘scope’ provides access to the user’s federated profile.

OpenID Connect extends OAuth2 Scopes. First with the ‘openid’ scope to initiate the protocol with the Openid provider, then defines further scopes that enable our application to access relevant parts of the federated identity profile.

With these extensions OpenID Connect allows our applications to authorize a user without accessing the user’s password at any time. Then within our application we can associate that user with a set of allowed actions or roles. Using the OpenID identity token and depending on the given scope our application may obtain allowed User profile information via a set of rest queries to associate with the role.

OpenID Connect allows applications a way to unify authentication for easier user management and security via the OpenID provider keeping a single store of usernames and passwords that can be used transparently across several internal applications.

When hooked into Social media services like Twitter, applications need to use a set of user APIs to allow authentication. OpenID Connect allows us to bring together these Social media APIs and simplify the process.

Most importantly with OpenID Connect an application does not need to store a user’s’ credentials for authentication. The application uses an external system that stores the user’s identity. This allows the separation of the authentication and authorization code. It allows developers to avoid the situation where every application has to manage a set of credentials for every user. It is also very convenient for users, since they don’t have to keep a set of usernames and passwords for every single application that they use.

OpenID Connect builds trust for the user. By using a chosen OpenID provider when a website is hacked and sensitive user data is stolen as a result of the applications failure to encrypt data and establish adequate firewalls the user if accessing the application via OpenID Connect can be sure their crucial identity data at the OpenID provider is secure.

There is no such thing as perfect security, users need to be responsible for the data personal and otherwise. However by implementing OpenID Connect we can go a long way to providing the security aware user with good choices.

Learn By Example

In this article we will build a simple OpenId client and configure the excellent WSO2 Identity Server. We will see how to configure and use the WSO2 Identity Server for OpenID authentication.

Step 1

Download the WSO2 Identity Server for your system and architecture from here.

Step 2 Install the server

Extract the binaries, rename the folder to wso2 and copy to somewhere on your system where you have read/write permissions. WSO2 needs Java 7, to get around this I run the WSO2 Identity server in VirtualBox.

Step 3 Run the server

a) find your java home, I usually find mine with

mvn -v

b) make a script that sets the JAVA_HOME system variable and runs the wso2 server start

Script mine looks like this

export JAVA_HOME=/usr/lib/jvm/java-7-oracle/jre
/home/ubu/wso2/bin/./wso2server.sh start

c) run the script and you should see the wso2carbon.pid to confirm that the identity server is running

d) Try to access the management console on the secure url

https://localhost:9443/carbon

Your browser will warn you about an untrusted certificate, choose to accept the risks

Be aware there is another interface called the dashboard it looks like this, at this point we will only work with the management console so if you find you are reading documentation for this interface you are in the wrong place.

At the sign-in screen, sign in to the Management Console using admin as both the username and password

Using WSO2 to manage Federated Entities.

Using the excellent WSO2 documentation or otherwise create a service provider. It is beyond the scope of this article to cover every aspect of the Identity server and the documentation is complete and accurate. We will cover the key points and illustrate them in screenshots, so persevere and when you see the result you can move on to the next step.

1) Add and register a Service, this will be our application.

Select register to create the service.

2) OAuth/OpenID Connect Configuration Entry Screen to Register A New Application

Open the Inbound Authentication Configuration tab

Note the WSO2 Identity server will automatically create your OpenID realm based on your application/service name, do not change this.

Select configure to create the application’s credentials

Enter the callback url http://localhost:8000/edusecure/oauth2client and select only the shown grant types

3)  Register a New Application for the Newly Created Service Provider

If you get this far your application can now authorise Users via OpenID. The next step is to create a Federated Identity for OpenID authorisation.

Creating a Federated Identity in the Wso2 Identity server

It is beyond the scope of this article to cover all the functionality of the Wso2 server, we will set up a federated identity and use it to access a secure rest api without a password, this is the key principle of OpenID. However Wso2 is an accessible and very well documented solution for application security, the documentation for all the functionality for the WSO2 Identity Server Management Console is found here.

Step1 select the Configure tab on the far left then select Users and Roles

Step 2 Add user and accept default role

Success

Now fill out the profile in User Profile



Run the Client application

For this application we will use the the source code for this article which is based on the Wso2 sample OpenID code. We have stripped out everything not needed for OpenID and simplified the code so the fundamental concepts implemented are easier to discern and learn from. This is a basic maven java application to be used to learn OpenID and if you are a Java developer could be used as a template to build from.

1) First copy the OAuth Client Key and Secret from the OAuth/OpenID Connect Configuration tab inside the Inbound Authentication Configuration tab

Into the eduonix.server.security.SecureUtils.java class

public static final String CONSUMER_KEY_VALUE = "< key value here>";
public static final String CONSUMER_SECRET_VALUE = "<secret value here>";

Load and build the sample code into a maven friendly IDE or build the code with maven from the command line.

mvn clean install

2) Once you have built the sample code you can run the application using the maven jetty plugin. With the WSO2 server running, we can run the application from the command line. In the same directory as the clients pom.xml type

mvn jetty:run

When you see the output below the server is ready and go to the following link in a browser

http://localhost:8000/edusecure/

Select login to start the OpenID dance.

This generates the first OpenID protocol request which will be similar too

https://localhost:9443/oauth2/authorize?scope=openid&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fedusecure%2Foauth2client&client_id=uZ9Rh5dfdhS8RAfRho_QpCuaJoQa

This follows the following schema

https://<OpenID provider>?<OpenID Scope><OpenID GRANT TYPE><CallBack URL><OAuth Client Key>

In the schema we call our application the client. We can always locate and change the client credentials in the OAuth/OpenID Connect Configuration tab located in the Inbound Authentication Configuration tab as shown below

We set the OpenID Scope and Grant type in the application’s source code.

Next we are redirected to this link on the OpenId identity provider which in this example is the local WSO2 server
Login with your federated identity credentials and you are taken to the approval page where you check and allow the applications OpenID claims

select approve and the WSO2 server will redirect to the application callback url  with an OAUTH ‘code’ token  to enter the final steps  of the OpenID dance. It looks like this and has the following schema.

http://<callback url>?<OpenID GRANT TYPE Value><token>

http://localhost:8000/edusecure/oauth2client?code=2d25676d747f7f137b2a4015da343db4

We use the ‘code’ token to obtain two more tokens

The code token looks like

This follows the following schema

Then we can call the token endpoint and using the code token obtain an OAUTH and OpenID identity token, they look like

OAuth2 access-token

6dbfbb616b9bdd1a74d813666cfa1e3a

OpenID id-token

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0=
.eyJleHAiOjQ5MTMxODQzOCwiYXpwIjoidVo5Umg1ZGZkaFM4UkFmUmhvX1FwQ3VhSm9RYSIsInN1YiI6ImVkdW9uaXh1c2VyQGNhcmJvbi5zdXBlciIsImF1ZCI6InVaOVJoNWRmZGhTOFJBZlJob19RcEN1YUpvUWEiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMmVuZHBvaW50c1wvdG9rZW4iLCJpYXQiOjQ4NzcxODQzOH0=

Using the OAuth2 access-token we can make a OAuth2 request to the OpenID User Info endpoint and the WSO2 Identity server sends the user info as a Json response.

Summary

In this article we have only skimmed the surface for OpenID Connect. It takes a while to absorb the complexity of the terminology and code flows (dance) of the protocol implementation.

The simple source code and example with the excellent free WSO2 Identity server helps to illustrate the concepts and allow familiarity by grinding out a client implementation in a virtual machine.

OpenID Connect is not backward compatible with OpenID 2 or 1.  OpenID Connect a version 3 of the OpenID specification improved for security and implementation for resource poor application environments in the mobile and embedded space.

OpenID Connect builds on OAuth which has its own terminology, token set, scopes and more.  OpenID Connect forces constraints on the underlying OAuth2 protocol to try and ensure any security system using the protocol is designed properly,

In the next article we will carefully step through the code to illustrate the OAuth2 implementation that underpins and enables OpenID Connect.

About the Author

Tutor @ Eduonix

Administrator

View All Posts