An Illustrated Guide to OAuth and OpenID Connect

Today we have an agreed-upon standard to securely allow one service to access data from another. Unfortunately, these standards use a lot of jargon and terminology that make them more difficult to understand. The goal of this post is to explain how these standards work using simplified illustrations

In the “stone age” days of the Internet, sharing information between services was easy. You simply gave your username and password for one service to another so they could login to your account and grab whatever information they wanted!

Yikes! You should never be required to share your username and password, your credentials, to another service. There’s no guarantee that an organization will keep your credentials safe, or guarantee their service won’t access more of your personal information than necessary. It might sound crazy, but some applications still try to get away with this!

You can think of this post as the worst children’s book ever. You’re welcome.

Ladies and Gentlemen, Introducing OAuth 2.0

OAuth 2.0 is a security standard where you give one application permission to access your data in another application. The steps to grant permission, or consent, are often referred to as authorization or even delegated authorization. You authorize one application to access your data, or use features in another application on your behalf, without giving them your password. Sweet!

As an example, let’s say you’ve discovered a web site named “Terrible Pun of the Day” and create an account to have it send an awful pun joke as a text message every day to your phone. You love it so much, you want to share this site with everyone you’ve ever met online. Who wouldn’t want to read a bad pun every day, am I right?

However, writing an email to every person in your contacts list sounds like a lot of work. And, if you’re like me, you’ll go to great lengths to avoid anything that smells like work. Good thing “Terrible Pun of the Day” has a feature to invite your friends! You can grant “Terrible Pun of the Day” access to your email contacts and send out emails for you! OAuth for the win!

1. Pick your email provider
2. Redirect to your email provider and login if needed
3. Give “Terrible Pun of the Day” permission to access to your contacts
4. Redirect back to “Terrible Pun of the Day”

In case you change your mind, applications that use OAuth to grant access also provide a way to revoke access. Should you decide later you no longer want your contacts shared, you can go to your email provider and remove “Terrible Pun of the Day” as an authorized application.

Let the OAuth Flow

You’ve just stepped through what is commonly referred to as an OAuth flow. The OAuth flow in this example is made of visible steps to grant consent, as well as some invisible steps where the two services agree on a secure way of exchanging information. The previous “Terrible Pun of the Day” example uses the most common OAuth 2.0 flow, known as the “authorization code” flow.

Before we dive into more details on what OAuth is doing, let’s map some of the OAuth terminologies.

| | Resource Owner: You! You are the owner of your identity, your data, and any actions that can be performed with your accounts. |
| | Client: The application (e.g. “Terrible Pun of the Day”) that wants to access data or perform actions on behalf of the Resource Owner. |
| | Authorization Server: The application that knows the Resource Owner, where the Resource Owner already has an account. |
| | Resource Server: The Application Programming Interface (API) or service the Client wants to use on behalf of the Resource Owner. |
| | Redirect URI: The URL the Authorization Server will redirect the Resource Owner back to after granting permission to the Client. This is sometimes referred to as the “Callback URL.” |
| | Response Type: The type of information the Client expects to receive. The most common Response Type is code, where the Client expects an Authorization Code. |
| | Scope: These are the granular permissions the Client wants, such as access to data or to perform actions. |
| | Consent: The Authorization Server takes the Scopes the Client is requesting, and verifies with the Resource Owner whether or not they want to give the Client permission. |
| | Client ID: This ID is used to identify the Client with the Authorization Server. |
| | Client Secret: This is a secret password that only the Client and Authorization Server know. This allows them to securely share information privately behind the scenes. |
| | Authorization Code: A short-lived temporary code the Client gives the Authorization Server in exchange for an Access Token. |
| | Access Token: The key the client will use to communicate with the Resource Server. This is like a badge or key card that gives the Client permission to request data or perform actions with the Resource Server on your behalf. |

Note: Sometimes the “Authorization Server” and the “Resource Server” are the same server. However, there are cases where they will not be the same server or even part of the same organization. For example, the “Authorization Server” might be a third-party service the “Resource Server” trusts.

Now that we have some of the OAuth 2.0 vocabulary handy, let’s revisit the example with a closer look at what’s going on throughout the OAuth flow.

1. You, the Resource Owner, want to allow “Terrible Pun of the Day,” the Client, to access your contacts so they can send invitations to all your friends.
2. The Client redirects your browser to the Authorization Server and includes with the request the Client ID, Redirect URI, Response Type, and one or more Scopes it needs.
3. The Authorization Server verifies who you are, and if necessary prompts for a login.
4. The Authorization Server presents you with a Consent form based on the Scopes requested by the Client. You grant (or deny) permission.
5. The Authorization Server redirects back to Client using the Redirect URI along with an Authorization Code.
6. The Client contacts the Authorization Server directly (does not use the Resource Owner’s browser) and securely sends its Client ID, Client Secret, and the Authorization Code.
7. The Authorization Server verifies the data and responds with an Access Token.
8. The Client can now use the Access Token to send requests to the Resource Server for your contacts.

Client ID and Secret

Long before you gave “Terrible Pun of the Day” permission to access your contacts, the Client and the Authorization Server established a working relationship. The Authorization Server generated a Client ID and Client Secret, sometimes called the App ID and App Secret, and gave them to the Client to use for all future OAuth exchanges.

As the name implies, the Client Secret must be kept secret so that only the Client and Authorization Server know what it is. This is how the Authorization Server can verify the Client.

That’s Not All Folks… Please Welcome OpenID Connect

OAuth 2.0 is designed only for authorization, for granting access to data and features from one application to another. OpenID Connect (OIDC) is a thin layer that sits on top of OAuth 2.0 that adds login and profile information about the person who is logged in. Establishing a login session is often referred to as authentication, and information about the person logged in (i.e. the Resource Owner) is called identity. When an Authorization Server supports OIDC, it is sometimes called an identity provider, since it provides information about the Resource Owner back to the Client.

OpenID Connect enables scenarios where one login can be used across multiple applications, also known as single sign-on (SSO). For example, an application could support SSO with social networking services such as Facebook or Twitter so that users can choose to leverage a login they already have and are comfortable using.

The OpenID Connect flow looks the same as OAuth. The only differences are, in the initial request, a specific scope of openid is used, and in the final exchange the Client receives both an Access Token and an ID Token.

As with the OAuth flow, the OpenID Connect Access Token is a value the Client doesn’t understand. As far as the Client is concerned, the Access Token is just a string of gibberish to pass with any request to the Resource Server, and the Resource Server knows if the token is valid. The ID Token, however, is very different.

Jot This Down: An ID Token is a JWT

An ID Token is a specifically formatted string of characters known as a JSON Web Token, or JWT. JWTs are sometimes pronounced “jots.” A JWT may look like gibberish to you and me, but the Client can extract information embedded in the JWT such as your ID, name, when you logged in, the ID Token expiration, and if anything has tried to tamper with the JWT. The data inside the ID Token are called claims.

With OIDC, there’s also a standard way the Client can request additional identity information from the Authorization Server, such as their email address, using the Access Token.

#web-development #security

What is GEEK

Buddha Community

PostgreSQL Connection Pooling: Part 4 – PgBouncer vs. Pgpool-II

In our previous posts in this series, we spoke at length about using PgBouncer  and Pgpool-II , the connection pool architecture and pros and cons of leveraging one for your PostgreSQL deployment. In our final post, we will put them head-to-head in a detailed feature comparison and compare the results of PgBouncer vs. Pgpool-II performance for your PostgreSQL hosting !

The bottom line – Pgpool-II is a great tool if you need load-balancing and high availability. Connection pooling is almost a bonus you get alongside. PgBouncer does only one thing, but does it really well. If the objective is to limit the number of connections and reduce resource consumption, PgBouncer wins hands down.

It is also perfectly fine to use both PgBouncer and Pgpool-II in a chain – you can have a PgBouncer to provide connection pooling, which talks to a Pgpool-II instance that provides high availability and load balancing. This gives you the best of both worlds!

PostgreSQL Connection Pooling: Part 4 – PgBouncer vs. Pgpool-II

CLICK TO TWEET

Performance Testing

While PgBouncer may seem to be the better option in theory, theory can often be misleading. So, we pitted the two connection poolers head-to-head, using the standard pgbench tool, to see which one provides better transactions per second throughput through a benchmark test. For good measure, we ran the same tests without a connection pooler too.

Testing Conditions

All of the PostgreSQL benchmark tests were run under the following conditions:

1. Initialized pgbench using a scale factor of 100.
2. Disabled auto-vacuuming on the PostgreSQL instance to prevent interference.
3. No other workload was working at the time.
4. Used the default pgbench script to run the tests.
5. Used default settings for both PgBouncer and Pgpool-II, except max_children*. All PostgreSQL limits were also set to their defaults.
6. All tests ran as a single thread, on a single-CPU, 2-core machine, for a duration of 5 minutes.
7. Forced pgbench to create a new connection for each transaction using the -C option. This emulates modern web application workloads and is the whole reason to use a pooler!

We ran each iteration for 5 minutes to ensure any noise averaged out. Here is how the middleware was installed:

• For PgBouncer, we installed it on the same box as the PostgreSQL server(s). This is the configuration we use in our managed PostgreSQL clusters. Since PgBouncer is a very light-weight process, installing it on the box has no impact on overall performance.
• For Pgpool-II, we tested both when the Pgpool-II instance was installed on the same machine as PostgreSQL (on box column), and when it was installed on a different machine (off box column). As expected, the performance is much better when Pgpool-II is off the box as it doesn’t have to compete with the PostgreSQL server for resources.

Throughput Benchmark

Here are the transactions per second (TPS) results for each scenario across a range of number of clients:

#database #developer #performance #postgresql #connection control #connection pooler #connection pooler performance #connection queue #high availability #load balancing #number of connections #performance testing #pgbench #pgbouncer #pgbouncer and pgpool-ii #pgbouncer vs pgpool #pgpool-ii #pooling modes #postgresql connection pooling #postgresql limits #resource consumption #throughput benchmark #transactions per second #without pooling

OAuth and OpenID Connect in Plain English

If you’re like Nate, you’ve heard about OAuth 2.0 and OpenID Connect, but have more questions than answers. What exactly are these protocols? Why do we need yet another set of standards for authentication on the web? How do they actually work?

In this talk, Nate will break down OAuth and OpenID Connect in plain language, and explain when and how you should use these standards in your applications. He’ll cover grant types, flows, scopes, tokens and what’s changed recently. If you’ve ever felt confused about how OAuth works, this talk is for you!

TIMECODES

• 00:00 Intro
• 02:07- Why do OAuth protocols exists?/the delegated authorization problem
• 04:53- Delegated authorization with OAuth 2.0
• 07:49- The OAuth flow terminology
• 13:32 What happened after OAuth?
• 15:01- New problem in OAuth
• 16:27- OAuth 2.0 and Open ID Connect
• 17:33 Current practice

#oauth #openid #security #programming #developer

Common Mistakes and Misconceptions in Web App Security using OAuth 2.0 and OpenId Connect

Authorization and authentication are two of main problems on modern web application’s security,. They were both solved by OAuth 2.0 and OpenId Connect(OIDC). But this is not the end of story. Like most things, the devil is in the details. OAuth 2.0 is an open standard for authorization. OpenID Connect extends OAuth 2.0 for authentication scenarios. Anyone can implement them. Considering them being fundamentally complicated, and variety of implementation, this may cause developers making some mistakes. I want to discuss some details in the specs which may lead to misconceptions and also go over common mistakes. For demo the implementation I use IdentityServer4 which is one of most popular open source frameworks for OpenID Connect and OAuth 2.0 on ASP.NET Core.

#oauth #openid #security #web-development #developer

An Introduction To Data Connectivity and Data Connectivity Solutions

In this article, we discuss facts about data connectivity, the related concepts, its benefits, as well as a discussion on some data connectivity solutions.

Introduction

In today’s world, data is the crux of major business decisions used by organizations all over the world. As such, it is imperative that the organizations have access to the right data and be able to analyze and make business decisions proactively. This article talks about data connectivity, the related concepts, its benefits, as well as a discussion on some data connectivity solutions.

#big data #data connectivity #data connectivity solutions #connectivity

Create PHP With MySQL Connection(Complete Guide) PHPCODER.TECH

https://phpcoder.tech/complete-guide-about-php-with-mysql-connection/

#php #mysql #connection #guide