What is OAuth 2.0

OAuth2.0 is a continuation of the OAuth protocol, but is not forward compatible with OAuth 1.0. OAuth2.0 focuses on simplicity for client developers, either through organization between resource owners and HTTP service providers. Approved interactions act on behalf of the user, or allow third-party applications to gain access on the user's behalf.

OAuth2.0 is a continuation of the OAuth protocol, but is not forward compatible with OAuth 1.0 (that is, OAuth1.0 is completely abolished). OAuth 2.0 focuses on simplicity for client developers. Either by structuring approved interactions between the resource owner and the HTTP provider on behalf of the user, or by allowing third-party applications to gain access on the user's behalf. It also provides dedicated certification processes for web applications, desktop applications and mobile phones, and living room devices. In October 2012, the OAuth 2.0 protocol was officially released as RFC 6749.

Foreword:

OAuth 1.0 is already in the IETF (International Internet Engineering Task Force), numbered RFC5849

This also marks that OAuth has officially become Internet Standard Protocol.

OAuth 2.0 has already been discussed and drafted. OAuth2.0 is likely to be the next generation of "user authentication and authorization" standard. Most open platforms such as Baidu Open Platform and Tencent Open Platform now use the OAuth 2.0 protocol as support.

OAuth (Open Authorization) is an open standard that allows users to let third-party applications access the user's private resources (such as photos, videos, contact lists) stored on a website without requiring the user to Name and password are provided to third-party applications.

OAuth

Allows users to provide a token instead of a username and password to access their data stored with a specific service provider. Each token authorizes a specific website (for example, a video editing website) to access a specific resource (for example, just the videos in a certain album) within a specific period of time (for example, within the next 2 hours). In this way, OAuth allows users to authorize third-party websites to access their information stored on another service provider without sharing their access permissions or the entire contents of their data.

OAuth is a complement to OpenID, but a completely different service.

OAuth 2.0

is the next version of the OAuth protocol, but is not backwards compatible with OAuth 1.0. OAuth 2.0 focuses on simplicity for client developers, while providing specialized authentication flows for web applications, desktop applications and mobile, and living room devices. In October 2012, the OAuth 2.0 protocol was officially released as RFC 6749 [1].

Facebook’s new Graph API only supports OAuth 2.0. Google also announced the Google API’s support for OAuth 2.0 in March 2011.

Authentication and authorization process:

The three parties involved in the authentication and authorization process include:

1. Service provider, user service provider to store protected resources such as photos, videos, and contact lists.

2. User, the owner of protected resources stored on the service provider.

3. Client, a third-party application that wants to access the service provider's resources, usually a website, such as a website that provides photo printing services. Before the authentication process, the client must apply for a client identity from the service provider.

The process of using OAuth for authentication and authorization is as follows:

The user wants to operate resources stored on the service provider.

The user login client requests a temporary token from the service provider.

After the service provider verifies the client's identity, it grants a temporary token.

After the client obtains the temporary token, it directs the user to the service provider's authorization page to request user authorization. In this process, the temporary token and the client's callback connection are sent to the service provider.

The user enters their username and password on the service provider's web page and then authorizes the client to access the requested resource.

After successful authorization, the service provider guides the user to return to the client's web page.

The client obtains the access token from the service provider based on the temporary token.

The service provider grants the client access token based on the temporary token and the user's authorization.

The client uses the obtained access token to access protected resources stored on the service provider.

A brief historical review

OAuth 1.0 was released at the end of December 2007 and quickly became an industry standard.

In June 2008, OAuth 1.0 Revision A was released. This is a slightly modified revision that mainly fixes a security vulnerability.

In April 2010, OAuth 1.0 was finally released in the IETF, protocol number RFC 5849.

The draft of OAuth 2.0 was released at the IETF in early May 2011.

OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.

OAuth is a security-related protocol that enables users to grant third-party access to their web resources without sharing their passwords. applications to access users' web resources without revealing their passwords to third-party applications.

OAuth 2.0 is a brand new protocol and is not backwards compatible with previous versions. However, OAuth 2.0 retains the same overall architecture as the previous version of OAuth.

This draft is based on the needs and goals of OAuth2.0 and has gone through a year-long discussion. Participants in the discussion came from various well-known companies in the industry, including Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom , Intuit, Mozilla, and Google.

New features of OAuth 2.0:

6 new processes

User-Agent Flow – the client runs within the user agent (typically such as a web browser).

Web Server Flow – The client is part of the web server program and accesses through http request. This is a simplified version of the process provided by OAuth 1.0.

Device Flow – Suitable for clients to perform operations on restricted devices, but the end user independently accesses the browser of another computer or device

Username and Password Flow – This process The use case is that the user trusts the client to handle the identity credentials, but still does not want the client to store their username and password. This process only applies when the user has a high degree of trust in the client.

Client Credentials Flow – The client uses its identity credentials to obtain an access token. This flow supports 2-legged OAuth scenarios.

Assertion Flow – The client exchanges assertion for access token, such as SAML assertion.

You can use the above multiple processes to achieve Native application support for OAuth (the program runs on a desktop operating system or mobile device)

application support (applications running on a desktop or mobile device) ) can be implemented using many of the flows above.

trustholder token

OAuth 2.0 provides an authentication method that does not require encryption. This method is based on the existing cookie verification architecture. The token itself will As a secret, send it via HTTPS, thus replacing the method of encrypting and sending via HMAC and token secret. This will allow using cURL to initiate API calls and other simple script tools without following the original request method and signing.

Signature Simplification:

For signature support, the signature mechanism is greatly simplified and does not require special parsing, encoding, and sorting of parameters. Use one secret to replace the original two secrets.

Short-term tokens and long-term identity credentials

The original OAuth will issue a token with a very long validity period (typically one year validity or no validity limit). In OAuth 2.0, The server will issue a short-validity access token and a long-life refresh token. This will allow the client to obtain a new access token without requiring the user to do it again, and also limits the validity period of the access token.

Separation of roles

OAuth 2.0 will be divided into two roles:

Authorization server is responsible for obtaining user authorization and issuing tokens.

Resource is responsible for handling API calls.

The above is the detailed content of What is OAuth 2.0. For more information, please follow other related articles on the PHP Chinese website!