Talk

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.

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.

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.

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.

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 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.

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.

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 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.

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.