pcjdev.github.io

An Introduction to OAuth 2.0

2019-07-04T00:00:00+00:00

OAuth 2.0 is an open standard for authorization, published as RFC 6749 and RFC 6750 in October 2012.

OAuth 2.0 enables a third-party application (client) to obtain limited access (via an access token) to an HTTP service (resource), either on behalf of an end-user (resource owner) or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol.

Roles

OAuth defines four roles:

resource owner (eg. the end-user)
resource server (the server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens)
client (the application making protected resource requests on behalf of the resource owner)
authorization server (the server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization)

Obtaining Authorization

To request an access token, the client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token.

OAuth defines four grant types (plus and extension mechanism for defining additional grant types):

authorization code
resource owner password credentials
client credentials
implicit

The authorization code grant is the most used type, for apps running on a web server, browser-based and mobile apps. For other use cases, see here a decision tree about which flow to use.

The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

OpenID Connect

OAuth 2.0 describes patterns for granting authorization but does not define how to actually perform authentication. One interesting and useful extension of OAuth 2.0 is the OpenID Connect protocol.

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

Reference

How to Create a Free, Fast and Secure Website with Jekyll and GitHub Pages

2019-06-29T00:00:00+00:00

A static website has noteworthy advantages over a dynamic one, like improved performance and security.

Here is a simple (and opinionated) way to build a static website, with Jekyll and GitHub Pages.

Step 1: Create the repository

Create a new repository named username.github.io, where username is your GitHub username, and clone it:

git clone https://github.com/username/username.github.io.git

Step 2: Create the bare minimum website structure

You can create a Jekyll GitHub Pages website with just a simple text editor, without being necessary to install any additional software on your computer (Ruby, Jekyll, Bundler).

Here is an example using the default Jekyll theme, minima, which is also one for the supported GitHub themes. Note that the pages in this example are created in Markdown, with front matter.

Create the files:

cd username.github.io
touch _config.yml index.md about.md

with the following content:

_config.yml - the Jekyll configuration file, in YAML format

theme: minima

title: Simple GitHub Pages website with Jekyll
author: your_name
description: >
  This is a simple GitHub Pages website with Jekyll

show_excerpts: false

minima:
  date_format: "%Y-%m-%d"

twitter_username: your_username
github_username: your_username
rss: rss

plugins:
 - jekyll-feed
 - jekyll-seo-tag

index.md - the homepage of your website

---
layout: home
---

about.md - the about page

---
layout: page
title: About
permalink: /about/
---

A simple GitHub Pages website with Jekyll.

Step 3: Push the files to GitHub

Although is recommended to test on your local computer before pushing the changes to GitHub, if you’re impatient (and followed the above steps), you can now push the newly created files and see your blog live at https://username.github.io

git add _config.yml index.md about.md
git commit
git push

Step 4: Add the first blog post

Create the first blog post:

mkdir _posts
cd _posts
touch 2019-06-30-first-blog-post.md

with some content, like the standard Lorem Ipsum passage, used since the 1500s:

---
layout: post
title: "First Blog Post"
categories: web
---

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore
eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt
in culpa qui officia deserunt mollit anim id est laborum.

Step 5: Add more files

Here are some recommended files for any git repository:

.gitignore - customize it for your needs

# local bundle/gems install
.bundle

# gemfile - used for local testing
Gemfile
Gemfile.lock

# generated site
_site

# on macOS
.DS_Store

.editorconfig

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

README.md - file that usually holds the description of the git repository content

# Simple GitHub Pages site with Jekyll

A simple GitHub Pages site with Jekyll.

Step 6: Customization

The following defaults are set by GitHub, which you are free to override in your _config.yml file:

github: [metadata]
encoding: UTF-8
kramdown:
  input: GFM
  hard_wrap: false
future: true
jailed: false
theme: jekyll-theme-primer
gfm_quirks: paragraph_end

GitHub Pages & Jekyll override the following settings in your _config.yml file, which you cannot change:

lsi: false
safe: true
source: [your repo's top level directory]
incremental: false
highlighter: rouge
gist:
  noscript: false
kramdown:
  math_engine: mathjax
  syntax_highlighter: rouge

Default plugins are enabled by default and cannot be disabled:

- jekyll-coffeescript
- jekyll-gist
- jekyll-github-metadata
- jekyll-paginate
- jekyll-relative-links
- jekyll-optional-front-matter
- jekyll-readme-index
- jekyll-default-layout
- jekyll-titles-from-headings

With gem-based themes, some of the site’s directories (such as the assets, _layouts, _includes, and _sass directories) are stored in the theme’s gem, hidden from your immediate view. Yet all of the necessary directories will be read and processed during Jekyll’s build process.

You can customize the default theme, minima, but pay attention to the theme version:

open $(bundle show minima)

Step 7: Test the website locally

You can set up a local version of your Jekyll GitHub Pages website by creating a Gemgile with the github-pages gem and test your website locally.

The Gemfile and Gemfile.lock files are used by Bundler to keep track of the required gems and gem versions you need to build your Jekyll website.

Install Jekyll and Bundler:

gem install --user-install bundler jekyll

Then, create the Gemfile:

touch Gemfile
echo "source 'https://rubygems.org'" >> Gemfile
echo "gem 'github-pages', group: :jekyll_plugins" >> Gemfile
bundle install --path .bundle
bundle exec jekyll serve

Now you can browse your website locally at http://127.0.0.1:4000

By the way, from time to time, make sure you have the updated version of the gems:

bundle update

That’s all folks!

Reference

About this Blog / Disclaimer

2019-06-27T00:00:00+00:00

About this Blog

Programming is easy. You have some requirements, and you, the programmer are put in the position to translate those requirements into another language that the computer understands and executes. Well, this is my opinion - as everything else on here:

an idea that is believed to be true or valid without positive knowledge

Writing is not so easy. Because the target audience is fuzzy, not like the language that the computer understands. It’s you, the unique person, who stumbled over my blog, but also the future me.

The promise I make to the world, and me, is that I’ll do my best to present randomly complex ideas as clearly as possible, in fields such as programming, security and life.

Discalaimer

Any views or opinions represented in this blog are personal.

All content provided on this blog is for informational purposes only and the accuracy and the completeness is not guaranteed.