View source for OAuth 2.0 Concepts

=Internal=

* [[OAuth_2.0#Subjects|OAuth 2.0]]

=Overview=

According to [https://tools.ietf.org/html/rfc6749 RFC 6749 - The OAuth 2.0 Authorization Framework], OAuth 2.0 is an '''authorization framework''' that enables a third-party application - the [[#Client|Client]] - to obtain limited access to an HTTP service - the [[#Protected_Resource|Protected Resource]] - either on behalf of a [[#Resource_Owner|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 [[#OAuth2_Access_Token|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|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.

=<span id='TOFU'></span>Trust On First Use (TOFU)=

The OAuth delegation process involves the [[#Resource_Owner|Resource Owner]], so important security decisions can be driven by end user choice, instead of being configured in a centralized manner somewhere else. OAuth supports '''Trust On First Use''', which is a model in which first time security decisions are being made at runtime, with the user's involvement: the user is prompted and makes choices. The system then [[#Authorization_Decision_Storage|remembers]] the decision for later use. The decisions are usually presented in terms of functionality, not security.

=<span id='OAuth2_Primitives'></span>OAuth Primitives=

==Resource Owner==

The '''Resource Owner''' is usually the end user. The Resource Owner has access to the [[#Protected_Resource|Protected Resource]] API and can delegate that access, or some part of their authority, to a third-party [[#Client|Client]], but it does not do that directly, it does it via a [[#Token|Token]] issued by an [[#Authorization_Server|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==

A '''Protected Resource''' is the component the [[#Resource_Owner|Resource Owner]] has access to. Usually it is an API of some kind, and it is exposed by a <span id='Protected_Resource_Server'></span>'''protected resource server'''.

==Client==

The '''Client''' is a piece of software that consumes the protected API and wants to gain access to a [[#Protected_Resource|Protected Resource]] in behalf of a [[#Resource_Owner|Resource Owner]]. Some, if not most Clients are pieces of software running in the browser (user agent) the Resource Owner has access to. From the point of view of the Resource Owner, the Client is potentially untrusted, so the owner may not want to share with it the credentials protecting the resource. OAuth facilitates the generation of [[#Token|limited credentials]] issued separately for each Client and Resource Owner combination. A specific Client is authorized by the Resource Owner at the [[#Authorization_Server|Authorization Server]]. The process of defining the authorization boundaries for a specific Client is called '''authorization grant'''. This mechanism insures that a breached Client can not expose the Resource Owners’ credentials, since the Client never sees them in the first place.

The Client may <font color=darkgray>optionally</font> authenticate against the [[#Authorization_Server|Authorization Server]].

==<span id='Authorization_Server'></span>Authorization Server (AS)==

The '''Authorization Server''' (AS) is the OAuth component trusted by the [[#Protected_Resource|Protected Resource]] to issue [[#Token|OAuth Access Tokens]] to [[#Client|Clients]]. A single Authorization Server can protect multiple [[#Protected_Resource_Server|resource servers]]. This is an explicit architectural decision that shifts the complexity away from Clients and towards servers ([[#Authorization_Server|Authorization]] and [[#Protected_Resource_Server|resource servers]]). This makes the servers more likely targets for attack but it is significantly easier to make a single Authorization Server highly secure that it is to make a large number of Clients written by independent developers just as secure.

===Authorization Decision Storage===

Some Authorization Servers allow the storage of the authorization decision the Resource Owner takes the first time is faced with the situation. This is to support [[#TOFU|Trust On First Use]] policy.

=<span id='Token'></span><span id='#OAuth2_Access_Token'></span>OAuth Access Token=


The token represents a delegated right of access.

There are several token types:

==Bearer Token==

'''Bearer tokens''' are defined by RFC 6750. A bearer token means that anyone carrying the token has the right to use it, and it will be granted access to the [[#Protected_Resource|Protected Resource]] without demonstrating possession of a cryptographic key.  Because of their generality, bearer tokens need to be protected from disclosure in storage and in transport.

==Refresh Token==

==<span id='JWT'></span>JSON Web Token (JWT)==

=OAuth Grant Types=

There are four OAuth2 grant types:
# [[#Authorization_Code_Grant_Type|Authorization Code Grant Type]]
# second
# third
# fourth

==Authorization Code Grant Type==

=<span id='Profile'></span><span id='OAuth_Profile'></span>OAuth Profiles=

=To Process=

<font color=darkgray>

Identity. [https://en.wikipedia.org/wiki/Identity_management 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_Security_Concepts#Service_Account|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.

</font>