OpenID Connect – an introduction to authentication with OIDC 

My predecessors have repeatedly referred to the increasing importance of double authentication when it comes to increasing safety in the IAM sector. But the whole topic of IAM goes even further and is becoming quite innovative. I would like to talk about OpenID Connect (OIDC for short) and show the possibilities of transferring our data even more easily and securely. What advantages does the OIDC service offer me as an end user?

 

First things first: 

What is authentication and how does it differ from authorization?  

Isn’t it one and the same?

 

The answer is: no, they are two different things. Authentication involves verification and proving the person’s identity, much like showing an ID card, before allowing them to access the protected application. Digitally, authentication can be done in one of several ways:  

 

  • One Time Passcode (OTP) 
  • Digital Certificates 
  • Device Authentication
  • Biometrics (fingerprint, facial recognition, FIDO key)  

 

Authorization checks whether the user is authorized to access the application and whether there are any special (user-related) authorization restrictions. For example, the user could have certain privileges, such as administrator access or activation of advanced functionalities. Additionally, authorization can be used to limit access to a minimum.

OpenID Connect – Authentication on the shoulders of OAuth 2.0

To explain OIDC, you first need to understand what OAuth 2.0 is used for.

 

OAuth 2.0 is an authorization protocol and thus the basis of OpenID Connect (OIDC). It enables an application (app 1) to access the user’s data in another application (app 2), the so-called Resource Server. This gives app 1 permission to access app 2 on behalf of the user. (The app the user wants to use is also called the “Relying Party” because it provides access to a secure software application).

 

For example, if app 2 wants to view the user’s contacts, it can retrieve them from app 1. This is called Delegated Authority. All this happens without the user ever presenting a password to the second app. Only the identity provider the user is registered with knows the user’s credentials.

 

OAuth 2.0 solves the problem of highly critical password disclosure. I log in to one app with my user credentials and an OAuth flow is triggered. Without entering my password, I am redirected to the second app and authenticated, as this integration has been confirmed by the flow. The service of app 2 runs in the background while I am still in app 1. As a user, I usually don’t notice anything about the fast exchange process, apart from being asked for my consent.

 

The special aspect about this is that I, as the user, can control how much app 2 is allowed to pass on to app 1 (Level of Access). A so-called “access token”, i.e. an electronic authorization card related to the user, is exchanged with an access level between the two applications. As a user, I have control over the access level I want to grant to the third-party application. I can also control what period of time the application can access which of my data. I can also delete my password without breaking the integration. If I don’t want the third party to have access, I can revoke that connection at any time. In other words, I have the power to control my data securely. That’s what is meant by Delegated Authority.

OAuth 2.0 & OIDC in Interplay 

So, OAuth 2.0 only deals with authorization, not authentication. This is where OIDC comes into play:

 

Open ID Connect is an authentication protocol that supplies identity providers with additional user authentication and access control. It is a standard that adds the authentication step to OAuth 2.0 authorization because it builds upon it. Thus, app 2 not only receives the key from the identity provider, but also information about the user’s identity. This enables the user to log in simultaneously to several applications where they have to prove their identity (social media, profiles on websites, etc.).

 

In addition to the access token, a user-specific ID token is generated and exchanged. This signed ID token is passed to app 2 in a JSON based JWT format and can be handled. This way, app 2 can not only view the contact list, but also associate the contacts with my name, city or email address if I allow it.

OpenID Connect Application Examples

Famous examples of the OAuth 2.0 and OIDC flow are the widely varied uses of Google, Apple and Microsoft services with just one login.

 

For example, if I’m already signed in to Google, I can use my profile for one of Google’s services such as YouTube. After I give YouTube permission to pull information from my Google account, I can see all my subscribed channels and receive video suggestions based on my preferences without having to sign in to YouTube separately. With just one click (consent), I connect all Google services together. This principle works on any device.

 

Or who doesn’t know the popular app Lieferando? To make the payment process easier for hungry customers, they can simply log in with their Google account. Google sends the surname and first name to the app, so they can save themselves the extra step of registering on Lieferando.de. Simple as well as user-friendly.

open id connect 

  1. The user wants to use the service of app 1 (Lieferando), but Lieferando does not know where to send the pizza delivery to. This means that the name, payment data, address, etc. are needed.
  2. Lieferando prompts the user to authenticate with Google.
  3. Google asks the user for permission.
  4. & 5. When the user has given their OK, an access token (= key) is transferred from Google to Lieferando with all the information about the customer. This way, the order process can be completed successfully.

Bottom Line

The advantage of OIDC authentication protocols is obvious: I save valuable time by being able to access more applications with little effort. This means that as a user of multiple applications, I don’t have to log in multiple times everywhere, nor do I have to manage or remember all my passwords. If I’ve given an application too much power, I can control the process and revoke access or retrieval of data as necessary.

 

It’s easier and safer to access and use my online services – especially since the use of social media platforms has become an integral part of our daily lives.

 

Despite the simplification of everyday authentication and authorization on various platforms, you should definitely make sure that no app has more rights than necessary. Pay attention to what consents which app has and read the often-annoying data processing pop-ups carefully.

 

If you would like to use OIDC in your application or learn more about the technical details, contact us – we will be happy to advise you.

Author

Julianna

Related Articles

SAP Identity Management – An Introduction
SAP Integration Suite – The key to an intelligent enterprise
Menu