OAuth

from Wikipedia, the free encyclopedia
OAuth logo

OAuth (Open Authorization) is the name of two different open protocols that a standardized, secure API - Authorization for desktop - Web and - Mobile permit applications. OAuth 1.0 was developed from 2006 and released in 2007. OAuth 2.0, which is fundamentally different from OAuth 1.0, was published by the IETF in 2012 as RFC 6749 and RFC 6750 .

An end user ( user or resource owner ), with the aid of this Protocol, an application ( client or relying party access to its data allow () authorization ), which by another service ( Resource Server are provided) without secret details of his access authorization ( authentication ) to disclose to the client. The end user can thus allow third parties to use a service on his behalf. Typically, the transmission of passwords to third parties is avoided.

As the basis of OpenID Connect , OAuth 2.0 is now used in many Internet services for user authentication .

history

OAuth 1.0

OAuth 1.0 was launched in November 2006 when Blaine Cook developed the OpenID implementation for Twitter . At the same time, Ma.gnolia needed a solution that would allow its users with OpenIDs to authorize Dashboard Widgets to use their services. So Blaine Cook, Chris Messina and Larry Halff from Ma.gnolia met with David Recordon to discuss the use of OpenID with the Twitter and Ma.gnolia APIs for delegation of authentication. They agreed that there was no open standard for API access delegation at the time.

The OAuth Internet Forum was set up in April 2007 for a small group of implementers to write a draft proposal for an open protocol. Google's DeWitt Clinton heard about the OAuth project and expressed an interest in supporting it. In July 2007 the team issued an initial draft specification. On October 3, 2007, the OAuth Core 1.0 draft was released.

OAuth 2.0

A meeting was held at the 73rd IETF meeting in Minneapolis in November 2008 to discuss bringing the protocol into the IETF for further standardization work. The meeting provided broad support for the establishment of an OAuth working group in the IETF. This working group developed OAuth 2.0 and published it in RFC 6749 and RFC 6750 . The IETF OAuth working group is still leading the further development of OAuth 2.0 through numerous extensions and additions to the standard.

roll

There are four roles in OAuth 2.0:

Resource Owner
An entity (user) that can grant a third party access to its protected resources. These resources are provided by the resource server. If the resource owner is a person, this is referred to as a user.
Resource Server
The server (service) on which the protected resources (Protected Resources) are. He is able to grant access on the basis of access tokens. Such a token represents the delegated authorization of the resource owner.
Client
An application (relying party) that wants to access protected resources of the resource owner that are provided by the resource server. The client can be run on a server (web application), desktop PC, mobile device, etc.
Authorization server
The server authenticates the resource owner and issues access tokens for the area of ​​application (scope) permitted by the resource owner . Authorization servers and resource servers are often merged and operated together.

Token

OAuth 2.0 uses tokens to authorize access to protected resources. This means that a client can be granted access to protected resources without having to pass on the access data of the service to the client.

Access token
To access protected data on the resource server, an access token must be transmitted by the client as a representation of the authorization. The permissions associated with the access token can be specified using the scope parameter. On the one hand, the client can request the desired authorizations from the authorization server; The access token is only valid for a limited time.
Refresh token
A refresh token can be used to request a new access token from the authorization server if the access token has expired or become invalid. The refresh token is also valid for a limited time. This is usually chosen higher than that of the access token. Like the access token, the refresh token is sent from the authorization server to the client after authorization by the resource owner. Since the refresh token itself already represents the authorization of the resource owner, no further authorization needs to be obtained from the resource owner for this new request for an access token ( RFC 6749 Chapter 1.5).
The use of access tokens and refresh tokens has the advantage that the service life of the access token can be kept short (a few minutes) and thus the security of the protocol is increased, since the resource server does not have access to the long-lived refresh token because that In contrast to the access token, it is only exchanged between the client and the authorization server. If the Resource Server only checked the authorization on the first request, a revocation of rights would have no consequences. Access to data and services on the resource server would then still be possible for the client. However, since the lifetime of the access token is only a few minutes, an attacker acquiring the access token at a later date would not have any far-reaching consequences, as the authorization server can check the access rights when an access token is reissued on the basis of the refresh token.

Abstract OAuth 2.0 protocol flow

Protocol Flow from OAuth 2.0
  1. The client requests authorization from the resource owner. This authorization request can be made directly, but is preferably carried out indirectly via the authorization server.
  2. The client receives authorization from the resource owner. Authorization can take place via one of the four authorization grant types, or an advanced authorization process is used.
  3. The client requests an access token from the authorization server. To do this, he uses the authorization approval from the resource owner.
  4. The authorization server authenticates the client (permission to ask) and checks the authorization of the resource owner. If this is successful, he issues an access token.
  5. The client requests the protected data from the resource server. He uses the access token for authentication.
  6. The resource server checks the access token and, if valid, provides the required data.

Authorization Grant Types

In order to be able to optimally cover different use cases, four approval processes were defined (authorization code, implicit, resource owner password credentials, client credentials). Furthermore, the possibility of defining further grant types was kept open. So was z. B. in RFC 7523 the use of JSON Web Tokens (JWT) and in RFC 7522 those of SAML 2.0 .

Use case

Authorization Code Grant Flow

A user (resource owner) has stored a user account and some images (protected resources) on an online server F for photos (resource server) . He would like to have the images printed on a service D for color printing (client) . For this purpose, the service D should be given access to the user's images on the server F. Since this is a different service than the one that the server F may make available, service D must authorize itself with the server F so that access is granted. For security reasons, it would not make sense for the user to transmit his access data (user name and password) for the server F to the service D so that the service D can authenticate itself with the confidential access data. This would mean that service D would have unrestricted access to the data and functions in the user account at server F. Further access for service D could then only be prevented by changing the password.

In such a case, OAuth enables service D to access certain data released by the user, usually only temporarily, and without disclosing the access data to service D.

For this purpose, a link is placed on the service D page, which has the description "Load photos from server F" and initiates the process. The information about the project of Service D is already coded in this link.

The protocol sequence according to OAuth 2.0 looks like this in this case:

  1. The user (resource owner) is forwarded by a link to the server F, where he has to register (authorization request) . He is also shown which service wants to access which data (steps 1–6).
  2. The user agrees by means of a corresponding link (authorization grant) that service D may access his photos. Server F then creates an authorization code and communicates this to service D. At the same time, the user is redirected back to the service D page (steps 7-10).
  3. Service D now asks server F with the authorization code for an access token (step 11).
  4. Server F creates an access token and transmits it to service D (step 12).
  5. Service D can now access the photos from server F, each time transmitting the access token (step 13).
  6. Server F then delivers the protected photos of the user to service D (step 14).

Points 1–6 above correspond to points A – F in section 1.2 “Protocol Flow” of RFC 6749 or the abstract OAuth 2.0 protocol flow shown above.

OAuth 2.0 and OpenID Connect

OpenID Connect 1.0 is an identity layer based on OAuth 2.0. It enables clients to check the identity of the user based on the authentication by an authorization server. Furthermore, further basic information about the user can be obtained in an interoperable form ( REST ).

OpenID Connect enables clients of all kinds, including web-based, mobile and JavaScript clients, to receive any information about authenticated sessions and users at all. The specification can be expanded to include optional functions such as encryption of identity data, finding OpenID providers and session management. OpenID Connect expands OAuth 2.0 with all the necessary functions for a personalized login and single sign-on .

safety

On April 23, 2009, a vulnerability was discovered in the OAuth 1.0 log. It concerned the OAuth authentication flow (also known as Three-legged OAuth ', English 3-legged OAuth ) in OAuth Core 1.0 section. 6

Eran Hammer, who had previously been the central editor of the OAuth 2.0 specification, left the project at the end of July 2012 because, in his opinion, its complexity could hardly be safely implemented by most software developers.

Web links

Individual evidence

  1. ^ A b c Dick Hardt:  RFC 6749 . - The OAuth 2.0 Authorization Framework . [Errata: RFC 6749 ]. October 2012. (English).
  2. ^ Dick Hardt, Michael Jones:  RFC 6750 . - The OAuth 2.0 Authorization Framework: Bearer Token Usage . [Errata: RFC 6750 ]. October 2012. (English).
  3. ↑ RFC 6749  - The OAuth 2.0 Authorization Framework . Section 1.5: Refresh Token. (English).
  4. ^ Brian Campbell, Michael Jones, Chuck Mortimore:  RFC 7523 . - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants . May 2015. (English).
  5. ^ Brian Campbell, Michael Jones, Chuck Mortimore:  RFC 7522 . - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants . May 2015. (English).
  6. ↑ RFC 6749  - The OAuth 2.0 Authorization Framework . Section 1.2: Protocol Flow. (English).
  7. ↑ OpenID Foundation: OpenID Connect. February 26, 2014, accessed September 28, 2016 .
  8. ↑ Eran Hammer-Lahav: OAuth Security Advisory: 2009.1. In: oauth.net. April 23, 2009, accessed on July 30, 2016 (English): "A session fixation attack against the OAuth Request Token approval flow (OAuth Core 1.0 Section 6) has been discovered."
  9. ↑ Ragni Zlotos: Developer: "OAuth 2.0 less interoperable and less secure". In: heise.de. July 27, 2012, accessed April 21, 2019 .
  10. ↑ Eran Hammer: OAuth 2.0 and the Road to Hell. July 26, 2012, accessed April 21, 2019 .

Remarks