OAuth : Grants Types

The OAuth 2.0 specification is a flexibile authorization framework that describes a number of grants (“methods”) for a client application to acquire an access token (which represents a user’s permission for the client to access their data) which can be used to authenticate a request to an API endpoint. There are many supported grant types in the OAuth2 specification, and this library allows for the addition of custom grant types as well.

Supported grant types are as follows:
Authorization code grant
    The authorization code grant should be very familiar if you’ve ever signed into an application using your Facebook or Google account.
Implicit grant
    The implicit grant is similar to the authorization code grant with two distinct differences. It is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible. Secondly instead of the authorization server returning an authorization code which is exchanged for an access token, the authorization server returns an access token.
Resource owner credentials grant
    This grant is a great user experience for trusted first party clients both on the web and in native device applications.
Client credentials grant
    The simplest of all of the OAuth 2.0 grants, this grant is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required.
Refresh token grant
    Access tokens eventually expire; however some grants respond with a refresh token which enables the client to get a new access token without requiring the user to be redirected.

A grant is a method of acquiring an access token. Deciding which grants to implement depends on the type of client the end user will be using, and the experience you want for your users.   

OAuth terms:
Resource owner (a.k.a. the User) - An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
Resource server (a.k.a. the API server) - The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client - An application making protected resource requests on behalf of the resource owner and with its authorization. The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices).
Authorization server - The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Linux vs Windows Containers

Docker provides an additional layer of abstraction and automation of operating-system-level virtualization on Windows and Linux. Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs).

Similarities

Docker containers on Linux and Windows are similar in the following ways:

• They are designed to function as application containers.
• They run natively, meaning they do not depend on hypervisors or virtual machines.
• They can be administered through Docker (although you can also use PowerShell to manage containers on Windows).
• They are limited to containing applications that are natively supported by the host operating system. In other words, Docker for Windows can only host Windows applications inside Docker containers, and Docker on Linux supports only Linux apps.
• They provide the same portability and modularity features on both operating systems.

Differences

And here’s what makes Docker on Windows different:

• Docker supports only certain versions of Windows (namely, Windows Server 2016 and Windows 10). In contrast, Docker can run on any type of modern Linux-based operating system.
• Even on Windows versions that are supported by Docker, Windows has stricter requirements regarding image compatibility. Read more about those here.
• Some Docker networking features for containers are not yet supported on Windows. They are detailed at the bottom of this page.
• Most of the container orchestration systems that are used for Docker on Linux are not supported on Windows. The exception is Docker Swarm, which is supported. (If you want to use a different orchestrator on Windows, however, fret not; Windows support for orchestrators such as Kubernetes and Apache Mesos is under development.)