Introduction #
OAuth2 & OpenID is a complex topic, making it hard to cover in just one article. For that reason, my intention is to make series of articles, each one covering a specific implementation.
This is the part 1 of the series.
Le’s start by the simpest question, what is OAuth2?
Maintaining and implementing Authentication and Authorisation for your application is hard and requires deep security knowledge and architecture. It is a great responsibility to manage user’s credentials, as it is for the users difficult to trust owr service to store their personal data.
That’s why we need OAuth2. A standart to perform Authn/Authz in our application, giving this responsibility to third party Identity Management provider like Google, Microsoft and many more.
Furthermore, it is easier for the user to register or login, since most probably, one have already an account registered with one of these providers, which are trusted and easier to manage in a centralized place.
OAuth2 Flows #
Using OAuth2, we can secure a variety of resources. For example, we can authenticate Web API’s or Frontend Web UI’s. Each use case has a different implementation approach, and this is what are the OAuth2 flows.
They are basically the blueprints for the different OAuth2 use cases implementation.
These are the different OAuth2 Flows, which we will describe on a high level later in the article:
- Authorization Code Flow
- Client Credentials Flow
- Resource Owner Password Credentials Flow
- Implicit Flow
- Device Authorization Flow
- Refresh Token Flow
We will go through each one of the flows, on the next parts of the series, by implementing them in examples.
Terminology #
Before we go further, we need to make sure we understand the basic terminology.
Resource Owner
The resource owner is the user who already has an account in the Identity Provider (Google Login).
Client
The Client is our application, that want to perform the Resource Owner personal data, on dehalf of the Resource Owner.
Authorization Server
The Authorization Server is the application that knows the Resource Owner (already has an account and can login via SSO)
Resource Server
The Resource Server is the API which the Client want to use. For example, when the Resource owner login via Google Login (Resource Server), the Client (our application) can now access the Client’s Firstname & Lastname, from the Resource Server.
Redirect URL (Callback)
When the authentication is successfull in Authorization Server, the Resource Owner is redirected back to the Client. The endpoint which the Authorisation Server redirects the Resource Owner is the Redirect, or Callback URL. In that endpoint, the Client (our Application) can execute any login, for example, redirect the user back the the initial page that was requested, before the login.
Scope
These are the permissions the Client (our application) wants, in order to permorm Authorization (what data can the user access based on roles). Scopes can be for example, Read, Write, Delete, Update, etc…
Consent
Client ID
This is the ID that identifies the Client (Application) to the Authorization Server.
Client Secret
This is the passcode that only the Client and the Authorization Server knows, to perform Auhtentication between them.
Both the Client ID and the Client Secret were generated by the Authorization Server, for the Client to use them.
Authorization Code
This is a short lived code, which the Authorization Server sends to the Client. This code issent by the Client, back to Authorization Server for exchange with an Access Token.
Access Token
The Access Token, is the key that the Client will use from now on in order to request (and unlock) protected data in the Resource Server.
OpenID Connect (OIDC) #
OIDC sits on top of OAuth2. OIDC uses the OAuth2 flows and gives additional information about the Resource Owner.
Think of OAuth2 as a room key. It can give you access to the room (unlock the door), but you would not know the number of the room, or the floor you need to get in order to find the room. This is the extra information OIDC gives you.
The Access Token that is granted from Authorization Server using the OAuth2 Flow, means nothing to the Client (our application). It really only gives access to the client access stuff in Resource Server. However, using OIDC, the Client gets a ID Token along with the Access Token, and this IDToken the client can extract information from it, like the email of the Resource Owner, or the Lastname and the profile picture URL. The ID Token, refers as JWT (JSON Web Token).
/*54745756836*/
