DEV Community: Andrii Bui

Authorization & Authentication from backend perspective pt1

Andrii Bui — Sun, 05 Jun 2022 10:16:51 +0000

Introduction

I keep doing my tech blog here: https://andreyka26.com/

To be honest I planned to write this article about a year ago, because for a long time the authentication & authorization process was for me kind of not so clear. I didn’t find any book or article which in simple words can show the whole picture of that process, especially digging into details.

So in that article we are covering:

What is auth
What types of auth could be
As one of the types we will consider Basic and Digest(with our samples in .NET).
In the next part of this article we will take a look at OAuth and OpenId Connect.

This article should be useful for people who managed to get the RFC but didn’t get completely OAuth flow. I am here to help you, because I was in the same situation.
Note: I am using official info like RFC or the documentation provided by specific tools, so you can check everything by yourself if you want to.

Git repository with samples: https://github.com/andreyka26-git/dot-net-samples/tree/main/AuthorizationSample

Definitions

Prior to starting to talk about different approaches to authentication and authorization, we should consider the definitions.

1. Authorization & Authentication
From Wikipedia: “Authorization is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular”.

From MSDN: “Authorization is the process of determining whether a user has access to a resource. Authentication is the process of determining a user's identity”.

From Martin Fowler’s blog: “Authorization defines whether a user is allowed to do something.
Authentication confirms that the users are who they claim to be”.

You could pick up whatever definition you like, they are basically the same.
I unite Authorization & Authentication to “auth” because most usually (and in examples we’ll see that) - the authorization is impossible without authentication. If you don’t know who the User is - you cannot say what the User is allowed to do via Client.

2. API or Resource Server

In terms of OAuthit is named “Resource Server”, but for simplicity let me put it in the following way: it is the Server (just a piece of software running on some machine) that handles requests from the Client and sometimes needs the Client to be authorized to get the correct response.
Why sometimes? Because API may contain a public endpoint which doesn’t need auth at all. If all endpoints in the API are public (can be accessed without authorization) - there is no need to use auth. That’s why we will consider all endpoints on the API as protected ones.

3. Client
The Client is basically a piece of software which talks to the API and needs to authorize requests (when the endpoints are not public). Most usually this software runs on some device (mobile, desktop, and browser) and User is interacting with the API using Client.

4. User
In terms of OAuth the resource owner - is most usually a person who would like to use the Client and the application itself.

5. Authorization Server
This Server is fully responsible for identity of the user, authentication, and creating tokens. This enables you just to use some verification based on signatures (on Resource Server) and to not worry about implementation details of authentication.
We will use this term in the next part for OAuth and OpenId Connect. For this part it is not possible to decouple Authorization Server from Resource Server. So I will refer to API, Resource Server, Authorization Server or just Server as to the same thing in this part.

Flow

The basic flow looks like that:

The User wants to interact with the application somehow, this makes the Client send and receive data from API back and forth. Since the API has protected endpoints - it requires the Client to authorize its requests, and responds with 401 Not Authorized.
The Client then should firstly authenticate the user - make the request to the Server in order it confirms the User is who he claims to be. It may be the same Server where the API is serving or a standalone Server.
Most usually authentication is performed by sending the login and password (some identity) of the User to the Server which responds with a ticket (sequence of characters, typically signed or encrypted so the API can validate). This ticket can be used to access the API. Most usually this ticket is either a token or cookies (see section about OAuth and OpenId Connect). Meanwhile, for sure, the Server should have information about this user (to be able to say this login + password does exist and what he has access to).
The Client performs a request to the API including the authorization ticket (either token or cookies) - and then it can get the response from it.

The most common approach for implementing auth is to use auth tokens in headers. For sure there are other ways like sessions. But the main advantage of tokens is that they are stateless: you are not required to make other requests prior to the current one to be authorized. You only need to use the appropriate token.
The token is kept via request headers in the following format: “Authorization: ”.
Basically scheme means the way you can create or get your token and validate it, so let’s consider most popular auth schemes.

Auth schemes

There are many schemes that can be used to make the auth. There may be custom ones, but we will consider the most popular ones.
There are resources where you can find all commonly used schemes and RFC documentation for each of them: https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml.

Basic Scheme

RFC: https://www.rfc-editor.org/rfc/rfc7617.html
Wikipedia: https://en.wikipedia.org/wiki/Basic_access_authentication

It is the simplest auth scheme:

get username and password
concatenate them with “:”
encode with Base64
send request with Authorization header
Server validates username and password internally

Using this scheme we cannot decouple Auth from Resource server. So for each request the Server should get all info from the Authorization header, authenticate the User and then authorize him as well. It means that API should know who is the User (store him or know where to get it). To be able to decouple we will consider JWT tokens later on.

Note: encoding to base64 is needed for encoding special characters, to ensure the string contains only ASCII characters it will not give you any security layer.
Since the user passes his credentials in a raw state - it is required to use one more security layer on top of HTTP application layer - TLS.

Basic Auth Server: https://github.com/andreyka26-git/dot-net-samples/tree/main/AuthorizationSample/Basic.Server

Basic Auth Client:
https://github.com/andreyka26-git/dot-net-samples/tree/main/AuthorizationSample/Basic.WebClient

BasicAuthenticationHandler first does the authentication: it extracts username and password from header (decoding base64) and ensures this user does exist (in our case it is a simple if statement, but in real case it should hash the pass and check it along with username). It does it for every request, because we used .UseAuthorization() .UseAuthentication() middleware registration methods.

But this is the Authentication part of it, we only checked that the user is who he claims to be.
After BasicAuthenticationHandler did the authentication part we will have User.Identity in each endpoint, and based on this identity we can do Authorization - to verify whether this particular user is allowed to access this endpoint or not.

However Basic Auth is so simple it brings a few problems:

It is not secured, you need to send your unencrypted unhashed password through the network
It doesn’t have any defined way of logging out and logging in the user.
No built in protocol for giving different permissions for different endpoints, roles, etc. Meaning, that Resource Server will not have claims (role, static, etc) which it can validate in token. This forces each Resource Server to know all user permissions and store it inside.
The API should know user (store it)

Digest Scheme

RFC: https://datatracker.ietf.org/doc/html/rfc7616
Wikipedia: https://en.wikipedia.org/wiki/Digest_access_authentication

First of all I should mention that this sample I rewrite from this repo, so you can see original version: https://github.com/flakey-bit/DotNetDigestAuth

It is a little bit complicated auth flow compared to Basic Auth. It doesn’t pass a password through the network, instead of this we are creating and storing some hashes.

Using this scheme we cannot decouple Auth from Resource server. So for each request the Server should get all info from the Authorization header, authenticate the User and then authorize him as well. It means that API should know who is the User (store him or know where to get it). To be able to decouple we will consider JWT tokens later on.

This flow requires you to call the endpoint 2 times if you are not authenticated. First you should receive 401 with necessary headers and the next call is done with a generated digest token (on Client side) based on those headers.

Prior to explaining the flow we should introduce some terminology:

Username - just login provided by user
Password - just password provided by user
Realm - area which you can access with a particular digest ticket, something similar to scope in OAuth. You might return the same realm value for some particular set of endpoints and you will have access to those endpoints with the same auth ticket.
Nonce (number once) - Server generated string which should be unique for all 401 responses.
CNonce (client nonce) - Client generated string which should be sent and verified by the Client. The Server doesn’t care about it and includes it as a response so that the Client can confirm that it is the right Server. It is used for plain-text attack mitigation (when an attacker has a plaintext and encrypted version, based on that he could reveal secrets, code blocks, etc).
Nc (nonce count) - the number of requests (including the current one) that the Client has sent with the nonce value in it.
Opaque - Server generated string which should be sent unchanged by the Client.
Qop (quality of protection) - defines whether hash of entity-body is added to hashes or not. It brings additional integrity. It might contain either “auth” or “auth-int” values.
Response - in terms of Digest auth it is a kind of signature, just a hash, based on values that will be sent to the Server to be verified.

For this auth we may use different hash algorithms, but for simplicity we will use MD5.

The flow is the following:

The Client performs a request to Resource Server without any Auth.
The Client collects realm, qop, nonce and opaque from response header.

The Client generates request auth token:

First Hash (A1) = MD5 (username:realm:password)

Note: we can use MD5-sess algorithm, which essentially means to use the same algorithm, but in this format:

First Hash (A1) = MD5 (MD5 (username:realm:password):nonce:cnonce)

Why would we like to do it? It allows you to not care about user password. On top of that, I think, it allows you to use a different algorithm for hashing user credentials (username:realm:password) for security purposes. And for auth we can use another algorithm with nonce and cnonce value.

Second Hash (A2) = MD5 (httpMethod:requestUrl)

Response = MD5 ({First Hash}:nonce:nonceCount:cnonce:qop:{Second Hash})

The Client sends the same request including Authorization header in following format: Digest username=”{username}”, realm =”{realm }”, nonce=”{nonce}”, uri=”{uri}”, qop={qop}, nc={nc}, cnonce=”{cnonce}”, response=”{response}”, opaque=”{opaque}”

The Server verifies the hash by using values provided by the Client (authenticate and authorize). Then it either rejects with a 4XX error, or serves the response.

There is one interesting question: How is the Server supposed to generate the first hash without knowing the password, since the Client doesn’t pass it on request?

And there are 2 main solutions:

we either store plain passwords (VERY VERY BAD APPROACH),
or we store hashed value of (username:realm:password) to be able to get the hash by username and realm. And this brings another problem. Once you want to change a hash (for example you used firstly MD5 and then some security weaknesses were detected and you want to change to SHA-256) you cannot do much.

Comparing to Basic Auth this flow fixed a lot of problems:

There is no plain password passed through the network
You can configure nonce lifetime to allow access only for some certain period of time. It is possible to log out all users by changing opaque value, this will force everybody to reauthenticate.
You can specify different access areas (different controllers, endpoints, etc) via realm.

However it still has some problems:

No built in protocol for giving different permissions for different endpoints, roles, etc. Meaning, that Resource Server will not have claims (role, static, etc) which it can validate in token. This forces each Resource Server to know all user permissions and store it inside.
The API should know the user (store it). You can fix it by storing a hash for a particular username and realm, but still it is some kind of knowledge of the user compared to JWT for example.

Conclusion

Basic Auth is pretty simple to implement but it has a lot of functionality and security lacks. Digest Auth is much more complicated, but solves some of the problems that Basic Auth has, but still it has some lack of functionality that regular applications would need for the Auth process.

So in the next part we will consider OAuth and OpenId Connect protocols which solved those problems.

To reach me out or to follow me:

Instagram: https://www.instagram.com/andreyka26_programmer/
Telegram: https://t.me/programming_space
Facebook: https://www.facebook.com/groups/719475658991936
LinkedIn: https://www.linkedin.com/in/andrii-bui-a55b39166/
GitHub: https://github.com/andreyka26-git

How I make myself productive with Google

Andrii Bui — Sat, 14 May 2022 14:15:04 +0000

Introduction

I keep doing my tech blog here: https://andreyka26.com/

Hello guys, in this article I'll explain to you why I've started using Google productive tools like Google Calendar, Google Keep, Google Tasks, and Google Docs. So basically everyone uses it in different ways - but I will show you my use cases and how they can be solved with mentioned tools and applications.

Google Tasks: use cases

For Google tasks I have three main use cases:

Instant task to not forget

Sometimes I find myself recalling something to buy or something to not forget to do, etc. This is the time when you can open Google Tasks. Since Google Tasks has a client application that can run offline, you can just get your phone and add your task. Whenever you will set an internet connection it will synchronize your task and you will be able to access it from other devices and the web.

For example, noting to buy something.

Planned task (possibly with email integrated into it)

Recently I've got a lot of such use cases because I had plenty amount of emails regarding relocation and start working for Microsoft. So I was getting different emails with action items to do (visa, health insurance, hardware pickup, etc.) You can integrate email, which possibly contains the date and place of an event with names and sender email, into the task with configuring reminder. And when the time comes you can instantly find your email and get all the necessary details. On top of that any other tasks without emails like haircuts, or other appointments with persons.

Just planned task:

Planned task with integrated email:

Create email clicking on this button

By default it creates task with the email subject

If you click on the "Test email button" you'll be redirected straight into the email.

Besides this, for email integrated tasks you can set reminders as well.

Regular/repeating tasks

This use case I mostly use when I have repeating tasks for some period of time: taking pills, body exercises, reminders for reading, etc.
For any repeating task - you could click on the "Date Time" button

And then go to the "Repeat" option.
Here just set repeating options.

Then you will get this task on your list repeatedly once a day along with reminders.

Google Tasks: Features I like

Back in the day, I used some kind of documents inside the phone or computer. I even used a regular notebook with a pen for tasks. And they all had some drawbacks which were used by what I am using right now.

Integration with Google environment. Most likely a huge amount of you (viewers) have your personal accounts in Gmail. So the first advantage of Google tasks is that it is integrated into the Google environment, so you can leverage other Google tools (Gmail, Calendar, Keep, etc).
It is free. You don't need to pay any money for a subscription for usage. You will need to pay only if you run out of overall Google Drive space (currently 15Gb), then you can extend to more space and you are okay.
It is cloud-based. It brings 2 advantages:

The data could unlikely be lost (replication, high availability, etc), and Google itself is responsible for that.
You can access your data from any device or from anything that has a browser and internet connection. Currently, I have 2 phones, my personal laptop, a laptop from previous work, current laptop from Microsoft. And all those devices are synchronized with Google Environment. If I add any task to one of those devices - this task will appear on all devices.

Simple and user-friendly interface. There aren't many functionalities, you can create different lists, only 1 level of hierarchy (task -> subtask), you can integrate with Gmail, you can set reminders, and add the "Details" section, but I don't think it is useful. And basically, this is pretty much enough for basic use cases
Reminders. On my phone, I can configure specific sounds for specific reminders (daily tasks, previous day's tasks, timed tasks). By doing that you can differentiate different tasks from notifications. And those notifications are working without an internet connection (the only one case is when you've added from another device and it wasn't synchronized with your current device, because you've not turned on the internet yet)

At some point when you have a lot of tasks and all of them has some dedicated time - it is important to not get lost in the list. For that purpose we can use Google Calendar.

Google Keep: use cases

Google keep is a tool for taking notes. Basically, I'm not that happy with it because I miss some functionality. Currently, I'm migrating to Microsoft OneNote for that reason.

I'm noting there everything relevant and important like addresses, phones, things to remember, maybe someone's words to not forget.

I'll note the advantages and disadvantages of it because for me it is not that good tool for notes.

Pros:

Google keep has decent performance on the phone, it is pretty quick
It can work without an internet connection, you need to turn on the internet connection only to make it sync with the server (and consequently with other devices).
Integration with Gmail. You can just open some emails, go to the tab with Google Keep, and start making notes. The email will be automatically attached to your note.

Now you can navigate to this email when viewing this note:

Pretty good system of labeling and colors (I actually don't use them, because I don't make many notes in Keep, mostly everything is in Google Docs now).
Integration with Google Docs: you can easily move your note to document in Google Docs.
You can attach a reminder to your note:

And will appear in Google Calendar:

Cons:

It doesn't contain any text editing tools like Google Docs contains. You can write plain text without any configuration of font size, font color, bold, italic other styles, font style, making lists with checkboxes.
Each note has 2 styles: "regular" and "checkboxes".

"Regular":

"Checkboxes":

I really don't understand the purpose of this, because you can do this checkbox behavior in Google Tasks. On top of that, I hate that it is applied to the whole note. So basically you cannot create one such "checkbox" list and then append regular text, and then do another "checkbox" list.

On top of that if you change your style back to the "regular" one it will clear all blank lines and another styling:

You can paste the photo, but it will be pasted on the top of your note, not in the place where you wanted it to be.

It doesn't contain integration with Google Tasks. For example, I faced situations when I need to attach Google Keep notes to Google Tasks but there is no such option.
For categorizing and structuring your notes between the categories you have only a labeling mechanism.

So personally for me - it is better to use Google Docs and Google Drive for noting everything.

But it is slower than Google Keep, and as I know you cannot edit it on the phone without an internet connection. On top of that, you need to swap Google Docs and Google Drive applications each time you need to get to another document which is not that great from a performance standpoint as well.

That's why I'm considering moving my notes to Microsoft OneNote.

Google Calendar: use cases

Basically, I'm using Google Calendar prior to the next day. Because Google Calendar includes all events, tasks, and reminders. Because sometimes you have a really huge amount of tasks for different days and you need to know what you are going to do only for tomorrow.
On top of that, it serves me as the connector of my notes and tasks together with my events and reminders in one place. I can see everything for a particular date in one place, and create everything as well from this place.

Conclusion

I find Google Environment so convenient for managing my life and tasks, it really simplifies and speeds up productivity. But from the taking notes standpoint, it is not that great. So I will appreciate your comments and ideas about how YOU use Google Environment or anything else for your productivity.