In a previous post, we talked about authentication servers and how they work. However, after a user’s identity is authenticated, the server needs to make sure that the requested information is supposed to be returned to that user. That is where authorization comes in.
Authorization is simply the process of verifying a user’s permissions and role after they have been identified. This process is usually carried out on dedicated authorization servers. These servers help protect sensitive data from unauthorized access through creating a centralized point of authorization management.
In this article, we will share an overview of authorization servers, how they work, and their significance in web development and security.
Key components
There are three key components to any authorization server:
Authentication: When a user requests information from a server, this component handles the verification of the user credentials, such as the JWT access token, to ensure that only authenticated users can obtain access to the data. This can also be handled by a stateful session ID as well.
Authorization: Once the user has been authenticated, this component is responsible for verifying that the user has the required permissions to access the information requested. Once verified, access tokens are issued for the respective resource.
Token Management: To maintain proper security measures with these access tokens, many authorization servers have this component to manage the lifecycle, issuance, and revocation of the access tokens.
How an authorization server works
There are three steps to how a basic authorization server works behind the scenes:
Granting authorization: If a user has already granted the necessary permissions, such as giving a website access to their Google profile while signing in with Google, the authorization server will typically generate an authorization code. Authorization codes are sent to the user by sending them back to the registered redirect URI.
Token request: Once the client possesses an authorization code, they then must exchange it for an access token to obtain access to a protected resource. This is typically known as a token request, whereby the client provides an authorization code, client ID, and client secret (if required). The authorization server then validates the request and issues an access token (and possibly a refresh token) to the client.
Accessing protected resources: Once the client has obtained an access token, they can use it to access the protected resource. Subsequently, the client will usually include the new access token in the HTTP Authorization header of every future request. The resource server will then validate the access token with the authorization server and return the protected resource to the client.
Authorization servers and protocols
Since the authorization server is responsible for granting and revoking permissions for users accessing protected resources, it needs to be able to keep track of who has permissions and who does not. It does this by issuing and managing access tokens, which serve as a “pass” for the user to access sensitive information.
In modern web applications, the most common protocol used to accomplish this is OAuth 2.0, which stands for Open Authorization 2.0. OAuth works by establishing several grant types, which are methods that users can use to acquire access tokens for protected resources.
Some of the common grant types are:
Authorization Code: Most websites and mobile apps you’ve used probably use this grant type. Users authenticate themselves on the authorization server, which provides an “authorization code.” The user then exchanges this code for an access token for the protected resource they want to see.
Implicit: More commonly used for SPA (Single-Page Applications), this grant type works by granting an access token to the user immediately, rather than requiring an authorization code first.
Client Credentials: This grant type is used when the client itself needs access to protected resources, rather than the end-user. Clients authenticate themselves with their client ID and secret and are granted an access token.
A note on OpenID Connect (OIDC)
There is another protocol built on top of OAuth that is often used by web developers to add an additional identity layer – OpenID Connect. OpenID Connect allows servers to authenticate users and obtain their basic information as well.
An authorization server that supports OpenID Connect can issue ID tokens alongside access tokens, providing user authentication and identity information in a single transaction. OpenID Connect and OAuth are commonly used in Single Sign-On (SSO) implementations. Utilizing OpenID Connect, allows you to login to different servers like YouTube using your Gmail account for example.
Benefits of using authorization servers
Implementing authorization is necessary when building any web application. Using centralized authorization servers to handle this sensitive process can provide many advantages, such as:
Centralized security: By housing the authorization processes in centralized servers, it can provide a single point of control for managing access control to protected resources, making it easier for administrators to enforce security policies and monitor access.
Improved user experience: Probably the most important advantage for companies is the ability to utilize protocols like OpenID Connect when building out authorization servers. This allows users to use something like a Google account to sign in to their own apps, effectively reducing the amount of passwords a user would have to worry about, as well as freeing up space and complexity on the server side from not having to store passwords. Also, it allows for users to authenticate once and access multiple applications without the need to log in repeatedly.
Enhanced privacy and security: Since the main application never handles any of the user authorization, the risk of data breaches and unauthorized access is reduced with the use of authorization servers.
By centralizing the authorization process, web developers not only enhance the security of their applications, but also simplify the development and improve the overall user experience. By understanding the role of these servers, and how it relates to OAuth 2.0 and OpenID Connect, you should be well-equipped to build a robust and secure application.
However, if you’d prefer someone else set up your authorization servers, Descope can help with that. Get started with one of our no-code flows and see how easy it is to implement authorization and authentication in your own projects and applications.
