Welcome to the 12th episode :)

While I said in the previous article that any software company will use three protection mechanisms to safeguard information i.e Encryption, Authentication and Authorization

We will see Authentication and Authorization in detail today

Knock.. Knock..

Who is it ?

Peter here. from Blue Stream Pluming service !

You open the door and see his ID and let access the kitchen faucet so that he can repair and leave.

This is exactly the process of Authentication and Authorization.

How ???????????

When peter knocked the door, you validated his identity - Authentication

He was not allowed to roam anywhere in the house, he can only go to the kitchen area to finish his repair - Authorization

Similarly when mobile application or web application wants to access an API in other place(cloud or third party) to fetch or post data it should first authenticate itself, once authenticated it can perform only operations that are designated to it and nothing else.

Conceptually....

Authentication is the process of proving you are who you say you are when accessing an application.

Authorization is the process of defining and enforcing access policies(permissions) i.e what you can do once you're authenticated.

How does it matter?

Maintaining data security entails ensuring that only the appropriate persons (and only the appropriate people) have access to sensitive information. It's difficult to identify and vet users every time access is sought, therefore authentication solutions help streamline the process.

For example, The company HR have access to all employee details, but she may not have access to their retirement savings account details which is only available to financial department head.

How is this enforced?

Using authorization policy, this ensures that different users have different access depending on their needs.

Authentication(AuthN)

The most common authentication factors are usernames and passwords. When the right credentials are given, a system considers the identity valid and grants access.

This is known as 1FA or single-factor authentication, and it's considered fairly insecure. Why? Because users are notoriously bad at keeping their login information secure. Multi-factor authentication (MFA) is a more secure alternative that requires users to prove their identity in multiple ways. This could be through

• Having a one time use pin code sent to your phone

• Authentication apps like Google Authenticator, Duo Mobile run by 3rd parties can be installed on your phone, that can generate one time password.

Good Reads: Authenticator apps

• Biometrics etc

When choosing a authentication process, there are some things that you need to know

• It should not be too complicated - if your use case was just running a free gaming service online, don't ask for bio-metrics.

• Enforce strict password schemes, we all know data breaches occur everywhere. you don't want your software application to be compromised!!! Passwords should be long with numbers and special characters.

Luckily, you don't have to build a authentication solution yourself, Auth0 is a wellknown platform that sits between your application(s) and Identity Providers like Google or Facebook that offer Single Sign-on (SSO), connecting and securing you and your data through standard APIs.

How is this done?

Through a token-based authentication method called JWT (JSON Web Token) which is good for stateless applications (and protocols, like HTTP).

Are there other ways to authenticate?

Another method for authentication over the web uses sessions and cookies.

Session vs. Token-Based Authentication.

Maintaining authentication (without hassling users) across a stateless HTTP connection is an important problem because no one wants to enter their password every time they make a request.

You can't ask the user to enter the password as they navigate between different pages of your application !!! Its should be Stateful !

Session-based authentication (an older method) relies on the server to track authentication. When a user logs in to a website on a browser, the server creates a session for that user. A session ID is assigned and stored in a cookie in the user's browser, preserving authentication while the user is on the site. Typically, cookies are deleted when a user logs off, but some browsers use session restoring, which keeps the session cookies in memory even after the user logs off. Much easier than logging in each time you want to access a page.

What is JWT?

Token-based authentication is different. When a user logs in, the server creates an encrypted token that allows users to perform any activity on the site. Instead of the server storing session IDs, the client stores the token, either in memory or in a cookie (much like session ids.)

JWTs is popular choice of token-based authentication because they save user data inside the token and can be validated without the database lookups mentioned above. This makes them well-suited for serverless and stateless applications.

https://jwt.io/

It has Header, Payload, Signature >> To learn more More

Why JWT ?

• Small (they transmit quickly)
• Secure (they're asymmetrically encrypted)
• Widely-used (JSON objects are everywhere !! virtually all programming languages have JSON parsers, and almost every big web API uses JSON)
• Transparent (their structure makes it easy to verify senders and that contents haven't been tampered with)

JWTs are not without their drawbacks. While they are encrypted, they cannot easily be revoked or invalidated on the server-side, introducing risk. Because of this, they typically use shorter expiration times.

Authorization (or AuthZ)

We still need to make sure that users can only access certain resources after they've been authenticated. Because illegal access to sensitive data may be so damaging, many firms implement access policies based on the 'least privilege' concept.

That is, you are only given access to what you require by default. Access can be segmented in a variety of ways

• Role-based (RBAC): Users are assigned to a certain group (or role) that comes with set permissions. Some examples may include "admin", "member" or "owner."
• Attribute-based (ABAC): Users are permitted access according to attributes like title, certification, training, and/or environmental factors like location. Sometimes known as "policy-based access control" or PBAC.
• Access Control Lists (ACL): Each user or entity has individual permissions that can be turned on or off, similar to installing a new app on your phone and deciding which permissions to grant (location services, contacts, etc.)

ACL is often employed at a finer level than ABAC or RBAC, such as to permit individual users access to a specific file. In most cases, ABAC and RBAC are implemented as company-wide policies.

OAuth 2

OAuth 2.0 (RFC 6749) is a widely used authorization framework enabling applications to access resources in all kinds of services.

Let's take an example, you developed a reminder app that basically reminds you of events that you have marked on your google calendar.

Your new app first needs to be registered with google and the API's that you built for the app can call the google calendar API's to pull user's calendar without knowing their user's usernames or passwords.

How's this possible?

OAuth defines four roles:

Resource owner An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

This is the user itself. In our case if its your phone with the Reminder app and google calendar. Its you the resource owner

Resource server The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

Houses the application and/or data owned by the user. Will allow access to a client if the client has a valid access token. Google calendar in the above example.

Client An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

This is the Reminder app

Authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

A 3rd party that verifies the identity of the user and the client, and issues access tokens.

The authorization server may be the same server as the resource server or a separate entity.A single authorization server may issue access tokens accepted by multiple resource servers.

Good Reads >> Oauth2 Oauth2 history

There are 4 different grant types that OAuth 2 uses. Think of each grant type as a way for an application to get an access token. These are:

• Authorization code grant The most common grant type, the client exchanges an authorization code in exchange for an access token.
• Resource owner credentials grant Allows a client to sign in directly using the resource owner's password.
• Client credentials grant Mainly used for server-to-server interactions, no resource-owner interaction required.
• Implicit grant This grant type was previously recommended for single page applications which couldn't keep a client secret. This has been superseded PKCE used with a standard authorization code grant.

Side Kick

Authentication is what your users can see !!!! Typing the username password :)

Authorization policies are less visible to users :)

Summary

• If you're asked to develop an authorization service, think carefully about your options (1FA vs. MFA, which criteria you'll need if you pick MFA, etc.) because they can have a significant impact on the user experience.

• You have a responsibility to protect sensitive data, but you also don't want to scare users away.

• If you're building a large, dynamic system in which users' needs change frequently and/or users can embody several different attributes, you can opt for Attribute-based Authorization (ABAC), but Role Based (RBAC) works well in simple cases.

• OAuth 2 works if you think you may be asked to design an app that'll interact with identity providers or other apps using APIs.

AWS offers Identity Access Management and there are many cloud providers that offers authN and authZ as a solution.

Okta is also popularly used

Basically, if you are the service provider( the owner of the software application) you employ these Identity Providers to do the authN and authZ work for you so you can continue to focus on your business soley.

Happy Learning :)