Written by Eliad Mualem

Authentication and authorizations are two of the less understood concepts in software development. The lack of standardization becomes even more confusing due to multiple system-to-system and users-to-systems interfaces, making the configuration of authentication and critical access that prevent system breaches more difficult. In fact, web service developers (such as websites, apps, and APIs) have no standard to rely on when creating the connection to their service. Every developer can implement the connection as they deem fit. This, in turn, leads to numerous vulnerabilities that hackers may take advantage of. Examples include access to another user's resources, performing actions while impersonating another user, stealing personally identifiable information, gaining access to a resource that should have been secured but is accessible to all, and more. Often, these issues arise as a result of using the wrong identity authentication and access authorizations methods.

Having understood why these aspects are critical, let us introduce the most frequently used protocols, even though this article cannot cover all the protocols and methods available, we’ll get to some of the key ones.

Authorization – Cookies and Tokens

The cookies we are familiar with are objects that the web service stores and sends to every visitor. After the first cookie is sent, the browser will resend it with every request to the same web service to store information on the sessions of that specific user. Cookies can also provide access authorizations. Logged—in users will be identified by the information their cookies possess and will have access to specific protected resources.

A token is also an object generated by the web service. However, unlike the cookies, it does not need to be stored. The token authentication is carried out only with the information already available on the token. The signature available on the token provides the server with the information it needs to ensure the token is authentic. The use of tokens also saves the server the need to access the database to validate the cookies every time the user sends a request which also removes the need to have a shared database in a multiple server scheme (depending on the implementation). Common token types include Bearer and MAC.

Both cookies and tokens are widely used. Almost all web services use one of them or both to connect users. However, when implemented the wrong way, they are vulnerable to hacker abuse. For example, cookies may carry parameters that associate the connection to the specific site with the user. Modifying the parameter will allow us to skip to the account of another user. Tokens, for their part, have their validation mechanism registers. Changing the mechanism to a weaker one of eliminating it may lead to mistaken validation of that token by the server. Both cookies and tokens are vulnerable to theft. In other words, if someone sniffs a specific user's traffic and that traffic is not encrypted (HTTPS), the sniffer will be able to steal and use the information to log in to that website, passing as the user whose identity was stolen.

Bearer tokens

Bearer tokens are a token type that is sent to the server following an authentication process. The token must constitute an encrypted string of characters that only the server can decode or verify. For example, it can be a string encrypted with the server's private key, which the server validates with its public key. Note that the content of the token is visible for anyone through the server's public key, but no one can modify its content.

Another example is JWT (JSON Web Token) which contains information on the same user in JSON format. JWTs are some of the most used tokens today.

Message Authentication Code (MAC)

MAC ensures that the information sent to the server by HTTP request has not been modified and is often used when encrypted communication (HTTPS) cannot be used. HMAC is one implementation of MAC that can be used as an access token that solves the stealth issue discussed above. To use HMAC, both parties communicating must exchange a shared secret and an ID associated with that secret. From that point on, every request made must contain the ID and the hash generated from the request (which represents the request, the secret, the date, and additional parameters). The server verifies the hash, and since the shared secret is never sent with the requests, it cannot be stolen. This mechanism resolves certain stealing attack forms against cookies and tokens. Even if a malicious party detects the user's traffic, it will not be able to pass as the same user or perform actions on his behalf.

Single Sign-On (SSO)

SSO is currently the most common authentication concept. It uses a third party (the identity provider) such as Apple, Facebook, or Google to execute the authentication for a specific web service. The main advantage of this login method is that users are not required to create a user account and memorize passwords. Instead, users will be required to remember a single password to the third-party website that validates the user's identity, then connecting to the service associated with it. The shortcoming (relatively negligible) is the dependence on that third party. For example, if Google is unavailable when the login needs to be authenticated, our access to the web service we need will be denied. Common SSO protocols include SAML and OpenID.

OAuth

Previously, users who wanted to permit applications to access their accounts had to provide their username and password. In doing so, they gave the application full access to their account, which is a potentially dangerous action. From that moment, the application had full access to the user's entire information and authorizations, including modifying personal details and passwords.

OAuth is an internet standard for providing access authorization with the help of a third party. It is a protocol that lets the app receive specific authorizations for a particular user account without giving the username and password. Instead, OAuth relies on a third party which the app asks for authorization on behalf of the user. Then, that third party provides the app with a token and the user's confirmation so the app can use specific permissions for the user account.

The writer is a security information researcher with Noname Security.