APIs and Authentication on the Jamstack

The core of the Jamstack architecture lies in "APIs" (application program interface), which gives static websites powerful dynamic functions. Through APIs, developers can shift complexity and add dynamic functionality to static websites. Accessing the API usually requires verification of the authenticity of the request, which usually comes in the form of Authentication (Auth), can be performed on the client or server side according to the service being used and the tasks to be completed.

Differences in various protocols lead to different authentication implementations of APIs. These authentication protocols and implementation details add additional challenges when integrating APIs into Jamstack sites. Fortunately, this is not out of order. Each protocol can be mapped to a specific use case, and the key to implementing authentication is to understand this.

To illustrate this better, let's dive into the various protocols and their best suited scenarios.

Agreement Overview

OAuth 2.0 is a common standard that authentication is followed today. OAuth is a rather flexible authorization framework that contains a series of authorizations that define the relationship between the client and the API endpoint. In the OAuth process, the client application requests an access token from the authorized endpoint and uses that token to sign the request for the API endpoint.

There are four main types of authorization—authorization code, implicit process, resource owner password and client credentials. We will study each one separately.

Authorization code authorization

Of all OAuth authorization types, authorization code authorization is probably the most common. This authorization process is mainly used to obtain an access token to authorize API requests after the user explicitly grants permissions. It follows a two-step process:

• First, users are directed to the consent screen (i.e., authorization server), where they grant the service permission to access their personal accounts and data.
• Once permission is obtained, the next step is to retrieve the access token from the authentication server, which can then be used to authenticate the requests of the API endpoint.

Authorization code authorization adds an additional layer of security by adding the step of requesting explicit authorization from the user compared to other authorization types. This multi-step code exchange means that the access token is never exposed and is always sent through a secure backend channel between the application and the authorization server. This way, an attacker cannot easily steal access tokens by intercepting requests. Google-owned services such as Gmail and Google Calendar use this authorization code process to access personal content in user accounts. If you want to learn more about this workflow, check out this blog post to learn more.

Implicit authorization

Implicit authorization is similar to authorization code authorization, but with one obvious difference: instead of having the user grant permissions to retrieve the authorization code and then swap it into an access token, it returns the access token immediately by redirecting the snippet (hash) part of the URL (i.e., the front channel) .

Due to the reduced authorization code steps, the implicit authorization process has the risk of token exposure. Since the token is embedded directly into the URL (and recorded into the browser history), it is easy to access if the redirect is intercepted.

Despite the vulnerability, implicit authorization is useful for user agent-based clients such as single-page applications. Since application code and storage are easily accessible in the client-side rendered applications, there is no secure way to protect the client key. Implicit flows become the logical solution to this problem by providing an application with a quick and easy way to authenticate users on the client. It is also an effective way to solve CORS problems, especially when using third-party authorized servers that do not support cross-domain requests. Due to the inherent token exposure risks of this approach, it is important to note that access tokens in implicit processes are often transient and never issue a refresh token. Therefore, this process may require logging in for each request to a privileged resource.

Resource owner password authorization

In the case of resource owner password authorization, the resource owner sends its username and password credentials to the authorization server, which then sends back the access token with an optional refresh token. Since resource owner credentials are visible in authorization exchange between client application and authorization server, there must be a trust relationship between resource owner and client application. Although obviously not as secure as other authorization types, resource owner password authorization provides an excellent user experience for first-party clients. This authorization process is best suited for situations where applications are highly privileged or work in the device operating system. This authorization process is usually used when other processes are not feasible.

Client credential authorization

Client credential authorization type is mainly used when a client needs to obtain an access token outside the user context. This applies to machine-to-machine authentication when it is not guaranteed that every access to a protected resource is granted explicit permission from the user. The CLI and services running on the backend are instances where this authorization type comes in handy. Instead of relying on user login, it passes the client ID and key to get the token, which can then be used to authenticate the API request.

Typically, in client credential authorization, a service account is created through which the application runs and makes API calls. This way, the user will not be directly involved and the application can still continue to authenticate the request. This workflow is quite common when an application wants to access its own data (such as analytics) rather than specific user data.

in conclusion

Jamstack sites rely on third-party services to implement complex functions, so carefully designing authentication solutions is essential to maintaining their security. As the main way to exchange data in Jamstack, the API is a large part of it. We looked at four different API request authentication methods, each with its own advantages and impact on the user experience.

We mentioned at the beginning that these four are the main forms of authentication used to request data from the API. There are many other types, which are very good overview on oauth.net. As a whole, the website has been delved into not only the types of authentication available, but also the entire OAuth framework.

Do you prefer one method over another? Do you have any usage examples that you can point out? Please share in the comments!

The above is the detailed content of APIs and Authentication on the Jamstack. For more information, please follow other related articles on the PHP Chinese website!