Security is an important aspect on the Internet. To access the services on the Internet, you must prove you are who you say you are. That’s the Authentication. It is a proof that your identity is genuine.
You must also be authorized to access the services. Authentication, on itself, does not give you valid access to everything. You should be rightful to gain the access. This is the basic difference between Authentication and Authorization – Authentication is a proven identity whereas Authorization is a right to access.
Lets 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 so that you can stream the videos. Until then, you can just browse the offered videos, you can not watch them. Once you start the subscription, you’re authorized to stream the videos.
Today, we will look into different Authentication and Authorization mechanisms generally used.
Authentication & Authorization mechanisms
Basic auth using credential
This is a single-step straightforward method of authentication using 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 the SSL. Addition of SSL impacts the latency though. Requests take longer time than usual. If need to be used unsecured, this method can very well be used in the internal networks where the chances of stealing the data through snooping are less.
Unique API key
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. Mobile app can now 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 consume the services. This hardly seems like a way of authentication but the 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 basic auth mechanism but there is still a danger of compromising the key over an unsecured network.
A more secured form of authentication where the process includes user to provide two or more than two piece of information to be authenticated. One is always the account password, whereas the other piece of information could be either unique to the user like fingerprint, faceID etc or something that user has and has private access to like credit card, smartphone etc. Generally, when a user is authenticated with the correct password, an extra information is asked to the user to verify. User could be asked to verify the PIN sent to their phone or they could be asked to answer the secret question, so on and so forth, there are multiple ways of getting the extra information.
Authentication & Authorization Standards
There are several industry followed standards to implement Authentication and Authorization. These standards are the specifications and regularly updated as per the need. Lets 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 and based on that decided 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. And hence the name – Security Assertion Markup Language. As per the specification, One SP may trust the assertions from different IdP. Same with the IdP. One IdP may provide assertions to multiple SPs. There is no specification of what authentication method an IdP may use. IdP 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 is a set of rules for the 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 both Authentication as well as Authorization. When used just for the Authentication, it is referred as the 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 this resources to the Client, Resource Owner first 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 which can be used for the authorized access to the resources. As this token is time-bound, client has to refresh the token after its expiry. OAuth 2.0 is well suited for the 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. Please check if you want to learn more about it.
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 an 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 Facebook, Google etc provides 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 which used to share this profile information in the 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 its simple design, are easy to consume.
Convenience in Authentication
Entering 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 Facebook like Facebook application, Instagram, Messenger etc, it will have to create different accounts for these services and then remember the username and password for all of them. Instead, if Facebook lets user create just one account for all of its services and whenever user tries to access any of the service, user just has to login once. This is a convenience for the user. Single Sign On (SSO) and the Federated Authentication(Federation) are two approaches which take care of this convenience. Lets understand the difference –
SSO vs Federation
Both SSO and Federation is used for the single authentication system where multiple services, instead of implementing their own authentication system, rely on the single authentication system. Then how they are different. Federation is a type of SSO. Once authenticated, it stores the user credentials and then provide the user based tokens to the service provider. So, the flow here is – the user tries to access a service, service provider will go to the Federation server and provide the username of the user, Federation server checks for the user and if authenticated provides the token to the service provider. Service provider has to totally trust the Federation server and its authentication process. The advantage here is – the user credentials are not shared with any of the service providers and not with the clients. SSO is somewhat different where the service providers needs its client to provide username and password to the SSO server every-time the sign in is required. That forces client to store the user credentials with itself and use them for further authentication.
I hope you enjoyed reading the blog and got the high-level idea of different types of authentication and authorization standards and mechanisms. Thank you!