Talk

OAUTH 2.1 explained simply (even if you are not a developer) !
Conference (BEGINNER level)
Room 8
Score 0.17
Score 0.18
Score 0.20
Score 0.20
The match becomes increasingly accurate as the similarity score approaches zero.

It is very difficult today to deploy an application on the web without dealing with OAuth2. Designed to better protect users, this authorization delegation protocol has become a standard in the industry.

However, haven't you cried trying to understand the concepts of OAuth2? Let's be honest, this is quite easy to get lost between the different roles and the multitude of flows of this protocol. And its complexity has discouraged more than one! However we can't deliver without it, so we try to setup some OAuth flow and usually... this is really painful.

But don't worry, whether you have a tech profile or not, this talk will help you to finally understand the intricacies of OAuth simply, including the new version 2.1, using analogies from everyday life!

Julien Top├žu
Shodo

I like to craft software with high business value using techniques from Domain-Driven Design, all powered by Xtreme Programming in the Kanban #NoEstimates philosophy. Member of the OWASP foundation, I evangelise on application security techniques in order to avoid being hacked properly.

Generated Summary
WARNING: This summary was generated using GPT based on the transcript, as a result spelling mistakes and more importantly hallucinations can be present.

OAuth 2.1
Junior Topsy's Journey

Junior Topsy, a French consultancy company specialized in software craftsmanship and domain driven design, welcomes us to an educational journey to learn how OAuth 2.1 works. To illustrate the main principles of OAuth, Junior Topsy takes us on a journey to the Globular Pest Hotel, where he plays the role of security manager.

The Revocation Problem

Through the example of Facebook, Junior Topsy explains the revocation problem that occurs when a user gives their password to a third party. He highlights the need for a better system to avoid such problems. OAuth was created to solve the problem of having to learn a new password for services like Gmail and Facebook when a user forgets their code. To fix the revocation problem, temporary, personalized access codes are distributed using booking reference numbers.

The Malicious Person

However, a malicious person was able to embezzle money from Dimitri's account by calling the hotel and pretending to be him and asking for his account and password. To prevent this from happening again, the hotel partnered with Rubber Hits so that customers can call and order pastries without having to give their credentials. In this use case, Dimitri has to give his credentials to a third party to access a resource, which is dangerous.

Gustav's Solution

To fix this, the process is changed and Gustav, the manager of the hotel, is called to verify Dimitri's identity. Gustav also provides an authorization code with a limited lifetime, so that the resource can be accessed for a short time only. This ensures that the resource is still in Dimitri's will when accessed.

The Context

This is a story about a resource server, an authorization server, a client, an end user and a resource. Dimitri is the end user who delegates the ending of his resources to a third party, which is the client. Rubber hits, the client, wants to get the pastry from the hotel to deliver it to Dimitri on his behalf. Facebook is an example of a client that needs authorization to access resources without needing the user's password. This process involves several actors, such as the resource server (Gmail), the authorization server (Google) and the client (Facebook). Google authenticates the user and sends an authorization code back to Facebook which can be used to access resources.

Gary's Problem

Gary is one of the contents of the hotel who came to Gustav's company and asked for help with external companies asking for money. A company found out that a competitor was trying to hack their system by pretending to be them and delivering pastries. To protect against this, the company implemented an authentication process to verify trusted contact addresses. This process ensures that any requests from unknown numbers are denied, preventing hackers from obtaining authorization codes and accessing their contacts.

Front and Back Channels

This summary explains the concept of front and back channels when it comes to exchanging information. A front channel is a communication channel where you cannot be sure that your information has been delivered to the right person and no one has intercepted it. A back channel is more secure, as it ensures that the recipient receives the information. An example of this is when a hotel guest receives an authorization code by mail, but then must exchange it for an access token in person at the reception desk. This is also used in the context of Facebook and Google, where Google sends an order to Facebook without any direct communication between them.

Hashing Function

Oauth is a protocol used to securely pass information between two parties. If a browser crashes, the recipient of the information is not sure if it was received, which is why it is referred to as a \"front channel\". HTTPS is more secure because it is synchronous and hard to intercept, so it is referred to as a \"back channel\". The most commonly used flow in Oauth is the \"implicit flow\", but there are security issues with this method. To demonstrate, two people participated in an example where one person was a \"bad guy\" and one was a \"good guy\". The good guy called the bad guy to authenticate a person, giving them an order number. The bad guy then heard or saw the order number and was able to intercept it. This summary explains how a person can use a hashing function to authorize access to a pastry shop. A person is asked to think of a secret number and relay it over the phone. The person is then asked to scan a QR code which will generate a hash function. The hash function is then used to verify that the person on the phone is the one authorized for access. This process ensures that the access code is not disclosed publicly, as the inverse of the hash function is nearly impossible to compute.

OAuth 2.1 Explained

OAuth 2.1 is a protocol to help protect user data when third-party applications request access from users. It involves the use of a code verifier, challenge, and an access token with limited scope. When a user grants permission to a third-party application, the application is issued an authorization code with the specified scope, which it can then exchange for an access token. This access token is limited to the specified scope, preventing the application from accessing any other user data. Oauth 2.1 also features support for pixie, redirect UI, and exact match. OAuth 2.1 is not a new version of the protocol but rather an updated specification that includes all the new recommendations. It was created to make it easier to understand and use the protocol, as it was difficult to read the 80 RFCs specification. The support for OAuth 2.1 is usually good in libraries used for web apps and developers are encouraged to give feedback on their experiences using it.

Conclusion

OAuth 2.1 is an updated version of the protocol that helps protect user data when third-party applications request access. It involves the use of a code verifier, challenge, and an access token with limited scope, as well as features like pixie and redirect UI. The protocol makes it easier to understand and use, with libraries good for web apps and feedback from developers.


You can also ask questions on the complete talk using Devoxx Insights