OAuth 2.0 Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 23: Line 23:
===Resource Owner Authentication Against Authorization Server===
===Resource Owner Authentication Against Authorization Server===


Resource owner authenticates against the Authorization Server, as an essential step to determine who the Resource Owner is and what rights they are allowed to delegate to the client. The Resource Owner authentication exchange passes directly between the user (user’s browser) and the Authorization Server and it is never seen by the Client application. OAuth has nothing to say on authentication methodology. This isolates the Client from changes in Resource Owner’s authentication method against Authorization Server.
Resource Owner authenticates against the Authorization Server, as an essential step to determine who the Resource Owner is and what rights they are allowed to delegate to the Client. The Resource Owner authentication exchange passes directly between the user (user’s browser) and the Authorization Server and it is never seen by the Client. OAuth has nothing to say on authentication methodology. This isolates the Client from changes in Resource Owner’s authentication method against Authorization Server.


==Protected Resource==
==Protected Resource==

Revision as of 23:38, 15 May 2019

Internal

Overview

According to RFC 6749 - The OAuth 2.0 Authorization Framework, OAuth 2.0 is an authorization framework that enables a third-party application - the Client - to obtain limited access to an HTTP service - the Protected Resource - 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.

Many materials refer to OAuth 2.0 as an authorization protocol. Other materials refer to it as an delegation protocol, because offers means of letting someone who controls a resource to allow software applications to access that resource on their behalf without impersonating them.

The protocol works by allowing the application to requests authorization from the owner of the resource and receive a token it can use to get access to resource, without needing to impersonate the owner. The token represents a delegated right of access, which can be as granular as needed: some actions may be permitted, and some not. OAuth is about how to get a token and how to use a token. The tokens are issued by an Authorization Server, which is a component that acts as an intermediary between resource owner and client.

OAuth was designed from the outset as a protocol for use with APIs: the primary use case is software client access to APIs.

OAuth2 Primitives

Resource Owner

The Resource Owner is usually the end user. The Resource Owner has access to the Protected Resource API and can delegate that access, or some part of their authority, to a third-party Client, but it does not do that directly, it does it via a Token issued by an Authorization Server. The Resource Owner authorizes specific Clients, at the Authorization Server. The extent of trust (permissions) a specific Client is supposed to have is specified during the conversation between Resource Owner and Authorization Server. This process is called authorization grant.

The Resource Owner is generally assumed to have access to a web browser.

Resource Owner Authentication Against Authorization Server

Resource Owner authenticates against the Authorization Server, as an essential step to determine who the Resource Owner is and what rights they are allowed to delegate to the Client. The Resource Owner authentication exchange passes directly between the user (user’s browser) and the Authorization Server and it is never seen by the Client. OAuth has nothing to say on authentication methodology. This isolates the Client from changes in Resource Owner’s authentication method against Authorization Server.

Protected Resource

Client

Authorization Server

OAuth2 Access Token

The token represents a delegated right of access.

OAuth2 Grant Types

There are four OAuth2 grant types:

  1. Authorization Code Grant Type
  2. second
  3. third
  4. fourth

Authorization Code Grant Type

To Process

Identity. Identity Management.

Identity Federation and Single Sign-On are related concepts.

Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to authentication and technical interoperability.

User's presence in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a security context.

There are software agents that perform actions on behalf of the user, and this is where OAuth is relevant - a user can delegate in a standard and secure way the authority of performing certain actions. Even the software agent (the OAuth client) operates under a different identity, it can still perform action on behalf of a user that may not be even logged in anymore. An example of such identity is an OpenShift service account.

Authentication. The whole point of an authentication protocol is to tell whether the user is present in the system.

Identity Provider (IdP) and Relying Party (RP).

Authentication protocols, single sign-on, SAML.

Authorization.