OAuth allows websites and services to share resources among users. It is widely used, but be mindful of its flaws.
Since the inception of distributed computing networks, one of the most difficult to crack security is continuous, single sign-on access (SSO) between multiple computers, each requiring login accounts. Import unrelated to access their services and resources. While still not fully implemented on the entire internet, it is now possible to access a myriad of completely unrelated websites with a single login. You can use passwords, phone, digital certificates, biometrics, two-factor authentication (2FA), or a multi-factor authentication (MFA) SSO solution to sign in to one place and not Enter other access credentials to access. So OAuth was born to do that.
Definition of OAuth
OAuth is a standard authorization protocol that describes how unrelated servers and services can provide authenticated access to content without sharing the original credentials. In authentication parlance, this is called secure, third-party, authorized user-agent.
OAuth history
Created and strongly supported from the ground up by Twitter, Google and others, OAuth was released as a standard in 2010 as RFC 5849, and quickly adopted widely. Over the next two years, it was significantly revised and version 2.0 of OAuth, released in 2012 as RFC 6749. Although version 2.0 has been widely criticized for many reasons mentioned. below, it is even more common. Today, you can add Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix.
OAuth example
The simplest example of OAuth is when you log into a website and it provides one or more ways to log in using another website / service’s credentials. You then click on the button linked to another site, another site that authenticates you and the website you originally connected to to record your logs later using the permissions obtained from the secondary site. two. Another popular example OAuth case might be a user sending files stored in the cloud to another user via email, when the cloud storage and email systems support OAuth (e.g. Google Gmail and Microsoft OneDrive). When an end user attaches a file to their email and browses to choose which file to attach, OAuth can be used in the background to allow the email system to seamlessly authenticate and browse to protected files without asking for it. second login to the file system storage. Another example, one given in OAuth 2.0 RFC, is an end user who uses a third-party print service to print image files stored on an unrelated web server. In any case, two or more services are being used by the end user for a transaction, and the end user will appreciate not being required to have a second login. For OAuth to work, client software of the end user (eg browser), related services, and authentication provider must properly support the OAuth version (1.0 vs. 2.0).
Explanation of OAuth
When trying to understand OAuth, it can be helpful to remember that OAuth situations almost always represent two unrelated websites or services trying to accomplish something on behalf of a user or their software. . All three must work together regarding approval in order for the completed transaction to be authorized.
It’s also helpful to remember that OAuth is specifically about authorization, not authentication directly. Authentication is the process by which a user / entity proves ownership of an identity that is presented, by providing a password or some other solely owned or presented element. Authorization is the process of allowing an subject to access a resource after successful authentication, usually somewhere else.
The original implementer described OAuth as similar to a car’s attendant key, which could be used to allow a waiter to temporarily drive and park the car, but it doesn’t allow the holder of access. Unlimited, as full as conventional keys. Instead, the car can only be driven a few miles, has no access to locked trunks or glove boxes, and may have many other limitations. Essentially, OAuth allows users, through an authentication provider that they have previously successfully authenticated, to give another website / service limited access authentication tokens to authorize. permissions for additional resources.
Also, OAuth 2.0 is a framework, not a protocol (like version 1.0). It would be like all car manufacturers agree on how the attendant will automatically request, receive, and use the attendant key, as well as the general look of the attendant key. What a waiter can do compared to full functionality will vary by car manufacturer. Just like in real life, the attendant and the car owner don’t need to care about how it all works. They just want it all to run as smoothly as possible when they deliver the keys.
How OAuth works
Let’s say a user is signed in to a website or service (OAuth only works when using HTTPS). The user then initiates a feature / transaction needs to visit another unrelated website or service. The following will happen (greatly simplified):
- The first website connects on the user’s behalf to the second website, using OAuth, providing the user’s verified identity.
- The second website generates a one-time token and a unique one-time secret for the transaction and related parties.
- The first website provides this token and secret to the user’s client client-initiated software.
- The client’s software sends the required and secret token to their authorized provider (which may or may not be a second page).
- If not authenticated with an authorized provider, customers may be required to authenticate. After authenticating, the client is asked for authorization approval to the second website.
- The user approves (or their software silently approves) a particular type of transaction at the website first.
- The user is given an approved access token (note that it is no longer a request token).
- User provides an approved access token for the first website.
- The first website provides an access token to the second website as proof of authentication on behalf of the user.
- The second site allows the first website to visit their website on behalf of the user.
- User sees that a successfully completed transaction is occurring.
- OAuth is not the first authentication / authorization system that works this way on behalf of the end user. In fact, many authentication systems, especially Kerberos, work similarly. What’s so special about OAuth is its web-based capabilities and its wide applicability.
Although not as simple as it may be, web programmers seem to be easily understood. Creating an OAuth-compatible website can be done in a matter of hours to a day (much faster if you did before). For a little more effort, authenticated website access can be literally extended to hundreds of millions of additional users. There’s no need for a website to host its own authentication system with massive scalability. You can find an example of a single HTTP transaction packet here.