Security with OAuth, OIDC, JWT and more
I've been working with authentication and authorization for almost the last 2 months. So, I've decided to write about it. At least, the mainly concepts.
I think it is important to start with this simple differentiation.
Authentication: is the proccess of verifying an identity. Wheter you are who you are saying. Usually, you have to probe that by showing something you and only you know. (e.g. User and password)
Authorization: is the proccess of verifing what an user can do. Ofc, it always comes after authentication.
Authentication
As I said before, authentication is when you probe your identity.
How can you do that? There are plenty of ways: user and password, touch id, face id, just a private key, etc. You can also have the chance to authenticate with Google, Github, etc. And in some cases, you will need to authenticate twice with a 2FA.
OAuth 2.0 is a framework that
... enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
Let's explain some of the entities that appear here
-
Third-party application (a.k.a. Client) is the web, desktop, mobile application that wants to access the service.
-
Service (a.k.a. Protected Resource) is where we are trying to get access.
-
Resource owner is the one who has access to that service. Usually, the user.
OAuth 2.0 Flow
Explain by example: "John wants to access Google Drive"
Actors:
-
Resource owner: John.
-
Client: Browser. (JS app, in this case. Might be a backend app)
-
Authorization Server: is the Google server where John's account and credentials are stored.
-
Resource Server: Google Drive (where John's files are stored).
Steps:
-
John opens the browser and access Google Drive URL.
-
John's authorization is requested.
The authorization request can be made directly to the resource owner, or preferably indirectly via the authorization server as an intermediary.
-
Here is where the authentication has place. John brings his Google credentials.
-
Google's authorization server checks wheter crediantials are ok.
-
If everything is ok, an access token is returned. Depending on the grant_type and client type (public or confidential), this token might be different and other steps might be added here. I'll talk about this later on this post.
-
From now on, this access token is used to get the protected resource.
As I want to keep this post as simply as it can be, I will just name and link them to the RFC section where they are explained.
-
Device (Note that this grant is added in a different RFC)
OpenId Connect + JWT
OpenId Connect works on top of the OAuth 2.0 protocol adding extra features for the authentication part.
What are these features?
-
Besides the access token, the client will receive and extra token, called id token, represented as a JWT (JSON Web Token). It will store user's claims.
-
A protected UserInfo endpoint to get more user's claims. To access this endpoint, the access token must be provided.
-
New flow called hybrid flow
Authentication and authorization is a very big world. There are more things to talk about such as PKCE or scopes. I really recommend to read about them. The RFCs, in this case, are not hard to read. You can also find a lot of documentation.
Security is a topic which is constantly changing and it's hard to be up-to-date. I'm not a jedi but you can always ask whatever you want. Just reach me in any of my social medias.
or
