Version 2 is expected to simplify the previous version of the protocol and to facilitate interoperability between different applications.
OAuth2 defines 4 roles :
The Third-Party Application: "Client"
The client is the application that is attempting to get access to the user's account. It needs to get permission from the user before it can do so.
The API: "Resource Server"
The resource server is the API server used to access the user's information.
The Authorization Server
This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.
The User: "Resource Owner"
The resource owner is the person who is giving access to some portion of their account.
Creating an App
Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.
Example: Registering a Goole Drive API
Redirect URIs
The service will only redirect users to a registered URI, which helps prevent some attacks. Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look like demoapp://redirect.
Client ID and Secret
After registering your app, you will receive a client ID and a client secret. The client ID is considered public information and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally, the service shouldn't issue a secret to these types of apps in the first place.
Authorization
The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.
OAuth 2 provides several "grant types" for different use cases. The grant types defined are:
Authorization Code for apps running on a web server, browser-based and mobile apps
Password for logging in with a username and password
Client credentials for application access
Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
Each use case is described in detail below.
In this blog post, you can get a clear understand about the process of a web application that consumes the service of an OAuth Authorization Server and an OAuth Resource Server. For instance, it will demonstrate by a simple PHP web application to upload files to Google Drive using Google Drive REST API V3. As a prerequisite, you needed to set up a web server on your local machine. Then get the project files from here and follow the instructions in GitHub Readme to deploy it on your localhost.
When you run the app, initially it will display a simple button to initiate the process by redirecting the user to the permissions page where users can grant access to the application.
https://accounts.google.com/o/oauth2/v2/auth?redirect_uri=http://localhost/DriveSubmIt/modules/submit.html&prompt=consent&response_type=code&client_id=30577338934-gr44qm3k4vga34bc2lkrmfbsjbuidkgd.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/drive&access_type=offline
redirect_uri - Indicates the URI to return the user to after authorization is complete
response_type=code - Indicates that your server expects to receive an authorization code
client_id - The client ID you received when you first created the application
scope - One or more scope values indicating which parts of the user's account you wish to access
As you can see that whenever you execute this you will be redirected to the screen where you want to select your Google account from this list of accounts and after that, it grants access to your account by allowing this you will be granted access to this application.
If the user clicks "Allow," the service redirects the user back to your site with an auth code.
Website Interface:
Your server exchanges the auth code for an access token. You never see the access token, it will be stored by the website (in session for example). Google also sends other information with the access token, such as the token lifetime and eventually a refresh token.
When you upload file it will use the session.
Message flow diagram:
