Security is an important aspect of the Internet. To access the services on the Internet, you must prove your identity. That’s the Authentication. It is proof that your identity is genuine.
You must also be authorized to access the services. Authentication, in itself, does not give you valid access to everything. You should be rightful to gain access. This is the basic difference between Authentication and Authorization. Authentication is a proven identity whereas Authorization is a right to access.
Let's understand this with an example. Consider a very famous video streaming service. You created an account for that service. You can now login into your account using the credentials. If you enter the correct credentials, you’re authenticated and eligible to use the service.
You also need to subscribe to the service to stream the videos. Till then you can only browse the catalog. Once you start the subscription, you’re authorized to stream the videos.
Authentication and Authorization Mechanisms
Basic auth using credential
This is a single-step straightforward method of authentication using a username and password. Of course, this way of authentication is less secure as the credentials, if not secured, can be compromised over the network using a man-in-the-middle attack. Sensitive information can be secured with SSL. The addition of SSL impacts the latency though. Requests take a longer time than usual. If needs to be used unsecured, this method can very well be used in internal networks where the chances of stealing the data through snooping are less.
Unique API key
An API key is a unique string value generated and assigned to each client. This unique key is then passed in each API call and validated. For example, a weather service provider can generate a unique key and provide that key to a service consumer, let’s say a mobile app. The mobile app can use this key in each API request and consume the services. That way, this mobile app, on different mobile devices, uses the same key and consumes the services. This hardly seems like a way of Authentication but a way of Authorization. It is often used for what it is not intended for, Authorization. Its main purpose was to provide Authentication to the user. It could be a way around the pitfalls of the basic auth mechanism but there is still a danger of compromising the key over an unsecured network.
Multi-factor authentication
A more secure form of authentication where the process includes the user providing two or more pieces of information to be authenticated. One is always the account password, whereas the other piece of information could either be unique to the user like a fingerprint, faceID, etc., or something that the user has and has private access to like a credit card, smartphone, etc. Generally, when a user is authenticated with the correct password, extra information is asked to verify. The user could be asked to verify the PIN sent to their phone or they could be asked to answer the secret question, and so on, there are multiple ways of getting the extra information.
Authentication & Authorization Standards
There are industry-followed standards to implement Authentication and Authorization. These standards are the specifications and are regularly updated as per the need. Let's look at some of the widely followed specifications in the industry.
Security Assertion Markup Language (SAML)
SAML is the oldest of the standards. There are 3 actors here. the Principal (User), the Identity Provider (IdP), and the Service Provider (SP). The Principal tries to access the services provided by the service provider. The SP in turn requests and gets the authentication assertion from the IdP. Based on that decides the authorization of the access, i.e. what all things the Principal can access. Assertions are the base of SAML. They are the standard XML formatted messages hence the name — Security Assertion Markup Language. As per the specification, One SP can trust the assertions from different IdP. Similarly, one IdP can provide assertions to multiple SPs. There is no specification of what authentication method an IdP should use. It is free to use any kind of Authentication mechanism. SAML is considered to be not suitable for mobile and hence is not considered when mobile is one of the supported clients for the service.
OAuth 2.0
OAuth 2.0 is a set of rules for authorized delegated access to the resources. It was originally defined with authorization in mind so that the resource access is shared between multiple parties. Now, it is generally implemented to be used for authentication and authorization. When used just for authentication, it is referred to as pseudo-authentication. There are three main actors here. The Resource Server, the Client, and the Resource Owner. Here, the client wants to access resource owners’ resources (private information) kept at the resource server. To provide access to these resources to the client, the resource owner has to prove its identity to the resource server. Once the resource owner is successfully authenticated, a time-bound token is provided to the client by the resource server that can be used for authorized access to the resources. Since this token is time-bound, the client has to refresh the token after its expiry. OAuth 2.0 is well-suited for modern authentication and authorization needs. It very well supports web clients as well as mobile devices. I have written a simple and elaborated article about OAuth 2.0 here.
OpenID Connect (OIDC)
OIDC, an authentication standard, is the third version after OpenID 1.0 and OpenID 2.0. It is based on the OAuth 2.0 specification and provides an extra authentication layer over it. OIDC’s main purpose is to provide authentication but it additionally provides the basic user profile information to the client. Hence, it is highly preferable where a third-party mobile app (Client) doesn’t want to bear the cost of implementing the sign-in functionality and the security aspects around it, like storing the user credentials securely. For such cases, big players like Meta, Google, Apple, etc provide a way for third-party apps to authenticate their users(Resource Owners) and give basic profile information like name, e-mail address, etc. to the client. The profile information is shared in the elegant JSON Web Tokens(JWT) format. This is one of the differences between the OIDC and its previous versions where the profile information was shared in XML format. OIDC gets all the benefits from the OAuth 2.0 specification. It is very simple to integrate and the JWT-based tokens, due to their simple design, are easy to consume.
Convenience in Authentication
Entering a username and password multiple times could sometimes be an inconvenience for the user. Consider Facebook’s example. If the user wants to use multiple services provided by Google such as Gmail, YouTube, Google Drive, etc, they will have to create different accounts for these services and then remember the username and password for all of them. Instead, Google lets users create just one account for all of its services, and whenever a user tries to access any of the services, they just have to log in once. This is a convenience for the user. Single Sign-On (SSO) and Federated Authentication(Federation) are two approaches that take care of this convenience. Let's understand the difference -
SSO vs Federation
Both SSO and Federation are used for the single authentication system where multiple services, instead of implementing their authentication system, rely on the single authentication system. How are they different then? Federation is a type of SSO. Once authenticated, it stores the user credentials and then provides the user-based tokens to the service provider. So, the flow here is —
The user tries to access a service.
The service provider will go to the Federation server and provide the username of the user.
The federation server checks for the user. Once authenticated, it provides the token to the service provider.
The service provider has to trust the federation server and its authentication process. The advantage here is that the user credentials are not shared either with any of the service providers or with the clients. SSO is different in a way where the service provider needs its client to provide a username and password to the SSO server every time the sign-in is required. This forces the client to store the user credentials and use them for further authentication.
Conclusion
This is a high-level idea of different types of authentication and authorization standards and mechanisms. I hope you enjoyed this article, and if you have any questions, comments, or feedback, then feel free to reach out.
Thanks for reading!