Skip to content

Instantly share code, notes, and snippets.

@carloswm85

carloswm85/authentication-and-authorization.md

Created February 24, 2024 03:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save carloswm85/a15926e02d16deb28349343dde648d66 to your computer and use it in GitHub Desktop.
Save carloswm85/a15926e02d16deb28349343dde648d66 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
authentication-and-authorization.md

AUTHENTICATION AND AUTHORIZATION

Possible methods:

  • Sessions
  • Tokens
  • JSON Web Tokers
  • Secured Cookies

Example: Authenticated User

  • With JSON Web Token. From project provided by Fernando Herrera in Flutter course.
{
	"id": "91c2a3b7-ada1-47cf-9d95-7f712ec8fcc9",
	"email": "test1@google.com",
	"fullName": "Juan Carlos",
	"isActive": true,
	"roles": [
		"admin"
	],
	"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjkxYzJhM2I3LWFkYTEtNDdjZi05ZDk1LTdmNzEyZWM4ZmNjOSIsImlhdCI6MTY5OTQ1NDQ1OCwiZXhwIjoxNjk5NDYxNjU4fQ.YFfuu00K65pYf2ZQOekigKMIVQ4PZT0MbnrkSgMZ5YY"
}

Authentication Types

Basic

  • The most simple way to deal with authentication is to use HTTP basic authentication. We use a special HTTP header where we add 'username:password' encoded in base64.
GET / HTTP/1.1
Host: example.org
Authorization: Basic Zm9vOmJhcg==

  • Note that even though your credentials are encoded, they are not encrypted! It is very easy to retrieve the username and password from a basic authentication. Do not use this authentication scheme on plain HTTP, but only through SSL/TLS.

    alt text

HMAC

  • Another way is to use HMAC (hash based message authentication). Instead of having passwords that need to be sent over, we actually send a hashed version of the password, together with more information. Let's assume we have the following credentials: username "username", password "secret".
digest = base64encode(hmac("sha256", "secret",     "GET+/users/username/account"))

This digest we can send over as a HTTP header:

GET /users/username/account HTTP/1.1
Host: example.org
Authentication: hmac username:[digest]
  • Right now, the server knows the user "username" tries to access the resource. The server can generate the digest as well, since it has all information.
  • Please note that the "password" is not encrypted on the server, as the server needs to know the actual value. This is why te name "secret" is preffered and not a "password".

OAth

1.0

Nothing.

2.0

  • OAuth 2.0 (Open Authorization 2.0) is an authorization framework that enables third-party applications to access certain resources on behalf of a user without exposing their credentials.
  • It is widely used for secure and delegated access in various scenarios, such as accessing APIs, logging in with third-party accounts, or authorizing applications to perform actions on a user's behalf.
  • OAuth 2.0 was intentionally designed to provide authorization without providing user identity and authentication, as those problems have very different security considerations that don’t necessarily overlap with those of an authorization protocol. Treating authentication and identity separately allows the OAuth 2.0 framework to be used as part of building an authentication protocol.

Components and Roles:

Role Description
Resource Owner The user who owns the data or resources being protected.
Client The application seeking access to the user's resources.
Authorization Server The server that authenticates the user and issues access tokens.
Resource Server The server that hosts the protected resources.

Flow:

  1. Authorization Request: The client initiates the process by redirecting the user to the authorization server for authentication. The request includes the desired scope of access and the redirect URI.
  2. User Authentication: The user provides credentials and grants permission to the client.
  3. Authorization Grant: The authorization server issues an authorization grant to the client.
  4. Token Request: The client exchanges the authorization grant for an access token by making a request to the authorization server.
  5. Token Response: The authorization server validates the request and responds with an access token.
  6. Accessing Protected Resource: The client presents the access token to the resource server to access the protected resources on behalf of the user.

Access Tokens:

  • Access tokens are short-lived credentials that represent the authorization granted to the client.
  • They are used by the client to access protected resources on the resource server.
  • Access tokens can have different scopes, indicating the level of access granted.

Refresh Tokens:

  • Optionally, a refresh token may be issued along with the access token.
  • It allows the client to obtain a new access token without requiring the user to re-authenticate.

Scopes:

  • Scopes define the specific permissions or access levels granted to the client.
  • Clients request specific scopes during the authorization process.

OAuth 2.0 is flexible and widely adopted, making it a standard for securing API access and enabling seamless user authentication and authorization across various applications and services.

Readings

OAuth 1.0 and 2.0

Explanation

Hands On

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment