In Chapter 4, we mentioned most websites use usernames and passwords for credentials. We also discussed how to re-use these login credentials for unsafe API access, so the API often requires a different set of credentials than the login information used to log in. go to the website. A common example is API keys. In this chapter, we consider another solution, Open Authorization (OAuth), which is becoming the most widely used authentication scheme on the web.
Make life easier for everyone
Have you ever completed a registration form as below?
Figure 1. Lock the product as seen on Microsoft’s Windows 8 registration form.
Enter a long key in the form field as the case above is very bad for the user experience. First, you must find the required key. Sure, it was right in your inbox when you bought the software, but a year later, you tried to remember it (Where is the email sent? What email did I use to sign up ?! ) enter a perfect thing – doing a typo or missing a character will result in failure, or may even prevent you from being locked out of your unregistered software!
Forcing users to work with API keys is a similar bad experience. Typose is a common problem and it requires users to manually perform a portion of the setup between the client and the server. The user must obtain the key from the server, then give it to the client. For tools that mean work automation, there is definitely a better solution.
Enter OAuth. Automation of key exchange is one of the main issues that OAuth solves. It provides a standard way for customers to receive a key from the server by taking users through a set of simple steps. From the user’s point of view, all OAuth requests are to enter login information. Behind the scenes, the client and server are chatting back and forth to get guests a valid key.
There are currently two cleverly named OAuth versions, OAuth 1 and OAuth 2. Understanding the steps in the process is necessary to be able to interact with APIs using them for authentication. Since they share a common workflow, we will learn the authentication steps of OAuth 2, then show how other OAuth 1 versions 2 are.
OAuth 2
To begin, we first need to know the components involved in an OAuth transaction:
- Users – A person who wants to connect the two websites they use
- Client – The website is granted access to the user’s data
- Server – The site contains user data
One goal of OAuth 2 is to allow businesses to adjust the authentication process according to their needs. Due to this scalable nature, APIs may have slightly different steps. The workflow shown below is a common process found among web-based applications. Mobile and desktop applications can use small variations in this process.
Along with that, here are the steps of OAuth 2.
Step 1 – User notifies the client to connect to the server
Users start the process by telling the client that they want it to connect to the server. Usually, this is by clicking on a button.
Step 2 – The client directs the user to the server
The client sends user information to the server’s website, along with a URL that the server sends back to the user after the user authenticates, called a callback URL.
Step 3 – User logs on to the server and grants client access
With a common username and password, the user will authenticate with the server. Currently, the server is sure that one of its own users is requesting that the client be granted access to the user’s account and related data.
Step 4 – The server sends user information back to the client, along with the code
The server will send the user back to the client (call the back URL from Step 2). Hidden in feedback is a unique authorization code for the customer.
Step 5 – Client exchanges code + secret key to obtain access code
The client receives the authorization code it receives and issues another request to the server. This request includes the client’s secret key. When the server sees a valid authorization code and the client’s secret key is trusted, make sure the client is the user or it is acting on behalf of the real user. The server responds to the access token.
Step 6 – Client retrieves data from server
At this point, customers can freely access the server on behalf of the user. Access token from Step 6 is basically another password to the user’s account on the server. The client sends the access code with every request so that it can authenticate directly to the server.
Refresh customer token (Optional)
Another feature introduced in OAuth 2 is the option to have expired token access. This is useful in protecting user accounts by increasing security – the faster the token expires, the less time token is stolen, similar to the way credit card numbers expire later. a certain time. The life of the token is set by the server. API in nature uses everything from hours to months. After achieving a longevity, the customer must request the server to provide a new token.
How is OAuth 1?
There are some key differences between versions of OAuth. What we mentioned above; Access token does not expire.
One difference is that OAuth 1 includes an additional step. Between steps 1 and 2 above, OAuth 1 requires the client to request the server to provide the required token. This token works like an authorization code in Oauth 2 and the code is exchanged to obtain an access token.
A third difference is that OAuth 1 requires electronic signing. We will skip the details of how signing works (you can find code libraries to do this for you), but it is worth noting why it is in a version and not a version that. Signing requests are a way to protect data from tampering while it moves between client and server. The signature allows the server to verify the authenticity of the requests.
However, today, most API traffic occurs on a secured channel (HTTPS). Recognizing this, OAuth 2 removed the signature in an effort to make the second version easier to use. The tradeoff is that OAuth 2 relies on other measures to provide data security during transport.
Authority
An OAuth 2 element deserving special attention is the concept of restricting access, called authorization. Go back to Step 2, when the user clicks the button to allow customers to access. Those rights, called scope, are another important feature of OAuth 2. They provide a way for customers to request limited access to user data, thus helping users trust customers. goods easier.
What makes the scope powerful is that it is client-based restrictions. Unlike the API Key, where the limits are set on the lock that affects every customer the same, the OAuth scope allows a customer to have X and other rights X and Y. The web can view your contacts, while another site can view and edit them.
Chapter 5 Recap
In this chapter, we explored the OAuth validation process flow. We compare the two versions, indicating the big difference between them.
The main terms we have explored are:
- OAuth: an authentication scheme that automates key exchange between client and server.
- Access Token: a secret code that customers get when successfully completing the OAuth process.
- Scope: the right to define customer access to user data.
next
In the next chapter, we will look at some of the basic concepts in API design, including how APIs organize their data so customers can easily access what they want.
Go to Chapter 6!