Identity authentication has played a vital role in cybersecurity. Technological advances over the past decade have made it relatively more secure, but bad actors have continued to adapt and find ways to commit fraud.
Without a robust authentication process, cybercriminals can easily steal your private information and other sensitive data that goes through the internet. Authentication provides a safer environment in the online space, making it possible for businesses to operate smoothly and people to do their online activities safely.
One of the more widely used identity verification processes is OpenID Connect (OIDC), which works on numerous applications. But what is OpenID Connect? How does it work?
OIDC is an open authentication protocol that allows clients to confirm a user’s identity by an authorization server. You can implement OIDC and OAuth2.0, leading to a single framework that secures APIs, mobile native applications, and browser applications.
OIDC is easier to integrate than something like Security Assertion Markup Language (SAML). It can work with various apps, providing easily consumed identity tokens while offering sufficient security options that meet the standard requirements.
What is OAuth 2.0?
OAuth 2.0 delegates user authentication to the service provider hosting the user account. It authorizes third-party applications to access the user account and provides this for web applications, desktop applications, and mobile devices.
OAuth 2.0 separates roles from the client, resource owner, and end-user. It is designed to support various client types that access REST APIs. OAuth2.0 works with applications on enterprise web or cloud servers.
An example of how OAuth 2.0 works is if a website prompts you to log in using your Google, Facebook, Linkedin, or Twitter account. It asks for user consent if a website can access data about your account without sharing personal information and passwords.
OpenID Authentication Flow: The 4 Types
OpenID Authentication has four types of flows. It is essential to be aware of each flow’s function. They have specific requirements that need to be met, with some that work better in certain circumstances.
1. Implicit flow
The Implicit flow’s design is to pass essential information about the user to the application. However, information such as when and how it was done should be included. This OIDC flow is specific and requires encryption or a signature.
The primary requirement of this grant type is to use a public/private key to encrypt or sign user details. The application determines the user details and ensures that it is from a legitimate source. This protects the user’s information since only the provider has the information using the private key.
Implicit flow is necessary for apps with no “back end” on the web server, like Javascript.
2. Authentication or basic flow
Authentication flow involves the provider sending a unique, one-time-use code exchanged by the back-end web service for an OAuth access token. The exchange must have client_id and client_secret, similar to the OAuth2.0 flow.
The web service should use this OAuth access token to confirm the code’s legitimacy. It can also ask for various types of user information that involve different scopes and claims requested.
The admin usually pre-approves these claims but can appear as permission requests in the consumer world.
Authentication flow is the opposite of Implicit since it is an option for apps with web-server logic, enabling back-end communication with the idP (OneLogin).
3. Hybrid Flow
A hybrid flow is a combination of Implicit and Authentication flows and is the most complex. The hybrid flow allows an access token to pass directly from both authorization and token endpoints at the same time.
The front channel access token is not as secure as the back channel token, leading to a short lifespan. Extensions are possible through back channel calls. Since this flow combines the previously mentioned ones, it takes some parts from their original functionality.
4. Client credentials grant
A client credentials grant is excellent for machine-to-machine authentication. The specific user is not authorized, but the credentials are verified, and a generic access token is returned.
This access token contains expiry information with its authenticity being verified without needing API calls. This makes it helpful in authorizing services involving latency.
How Does OpenID Connect Work?
OIDC may be a difficult concept to understand. Privacy and security have become necessary with any online activity, keeping personal information and data safe. This is especially true for businesses since identity theft and fraud are common occurrences, with millions being reported.
Because personal details are involved, you want a system that grants the user convenience and efficiency. OIDC provides a straightforward process that begins with the application and ends with the UserInfo endpoint.
OIDC begins with an application that uses an OAuth flow, asking the user to authorize a request. The client must include the OIDC scope plus other necessary details about the user.
Once the request is processed, the client will have an access and ID token from the authorization server containing information about them. The client can contact a special endpoint on the authorization called the UserInfo to receive any claims.
Below is a situational step-by-step process of how OIDC works.
1. User opens the app.
2. The app opens a browser and sends an authorization request.
3. The user authenticates using the provided method.
4. Server sends an authorization code
5. The browser forwards the code to the app.
6. The app creates a backchannel request with the authorization code.
7. Server verifies the client and responds with an ID, refresh, and access token.
8. The user validates the ID token, accepting the authentication.
In situational matters, apps will call for different authentication methods. OpenID providers have several options of authentication security to choose from but may combine methods for more robust security.
These methods include:
1. Username and password
2. SMS confirmation
4. Hardware tokens
5. Transaction authentication
7. CAPTCHAs
8. Computer recognition authentication
Where is OpenID Connect Used?
OIDC is used for several things, but the three most common are single-page applications (SPA), native and mobile apps, and single sign-on applications.
1. Single-page applications (SPA)
An SPA is a web application that loads a single HTML page and updates the page, responding to the user’s interaction and other events. If you are considering creating an SPA, you want to separate the hosts for the application and the API endpoints.
An example would be an application from a CDN server while the container-hosted microservices deliver the APIs, spreading across the instantiated hosts.
A cross-origin approach is also possible but is more restricted for security reasons. Cross-Origin Resource Sharing (CORS) offers a standards-backed approach that solves this need while maintaining sufficient security.
2. Native and mobile apps
Using OIDC on mobile apps is possible through a browser that’s used to forward the authentication request. There are three implementations that you can use: WebView, System Browser, and OS Specific View Controller.
You can provide the browser with an in-app WebView browser, choosing two different technologies. For iOS, one is more lightweight but older, the “UIWebView,” while the other is newer, called “WKWebView.” Neither of these will work for SSO because they do not share the same cookie jar.
3. Single sign-on applications (SSO)
Before establishing SSO, there are a few requirements it needs. These include existing and fresh SSO sessions, no client prompts, and sites sharing ACRs (authenticators).
Starting with existing and fresh SSO sessions, one thing you may forget is that the SSO session must match the client’s parameters. Additionally, the session’s duration can be configured with the client specifying the request.
If the client prompts for authentication, SSO will not be allowed. This will check back in with the user to log in again.
Finally, if a site does not have the same ACR in its requests and configuration, SSO will not occur. An example is the first site needing an HTML form, while the second requires a social login. If that happens, SSO cannot occur.
Providing Safety Through Authentication
The internet is a saturated space, where massive amounts of information and data circulate through websites, browsers, and apps.
Authentication plays a vital role in protecting all this information and preventing identity theft and fraud. Passwords, tokens, and biometrics have become popular authentication methods in several applications.
Over the years, developers have continued to improve different authentication processes to ensure more robust security. All this leads to a safer environment in the digital landscape.
Q5id offers straightforward and proven identity authentication solutions.
Contact us for more information and schedule a demo!
"*" indicates required fields
