Understand oAuth authentication

Participants:
1. Resource owner, user who has credential to access the resource, like yourself.
2. Resource server, a web server where a resource is stored in there, like google drive.
3. Authorization server, an authentication server which manages the user identity, and authenticates the user, tokens issued by authorization server can be trusted by Resource server.
4. Client, application used by user (most likely resource owner) to work on the resource

Configuration:
clientID: "fb266000-544f-4db6-957e-1e05f530bb18",          
The client app must first register itself to authorization server to obtain a unique client id -- a unique string representing the registered client app. So when authorization request comes authorization server knows which client sends this request, Client id is not confidential.

grantType: "authorization_code"
Indicate the client type, confidential or public

authorizationEndpoint: "https://oauthasservices-wba2e8af2.int.sap.hana.ondemand.com/oauth2/api/v1/authorize",
Authorization endpoint - used by the client app to obtain authorization from the user. The user's identity will be authenticated at this url by user identity provider, the authentication method can be Basic, SAML, client cert, etc. This is the first step to establish oauth connection.

TokenEndpoint: "https://oauthasservices-wba2e8af2.int.sap.hana.ondemand.com/oauth2/api/v1/token",
Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client id information.

redirectURL: "com.sap.fiori.client.debug://oauth2",
Redirection endpoint - used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.

OAuth authentication must be performed with TLS (https) connection, as token is passed in clear text.

Authentication process:

1. When client app needs to perform an oAuth authentication, it first needs to open a browser (or webview), and send the initial GET request to the authorization endpoint, the url also includes the parameter of
response_type (required)
client ID (required)
redirect url, 
scope
state
response_type should be set to "code" if grandType is set to "authorization_code". This request needs to be opened in a browser (or webView) user agent, so the web page can lead user to input his credential to finish the user authentication. The authorization server may validate the rediretURL with the value
registered in it to avoid sending the authorization code to malicious user agent.

Request sample:

https://server.sample.com/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz

        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

2. When user authentication is succeeded, authorization server will send back 302 redirect request. The authorization code (or error) is included in the redirect url as "code" (or "error") parameter . The response url parameters include
code (required)
state (required)

example:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

The webview or client app can parse this url parameter to get the authorization code string. If error happens, the url will include "error" parameter and "state" parameter.
example:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

The authorization code means user grands the client app to access the resource, and so as to use the authorization code to exchange the access token.

3. Once the authorization code is available, the webview opened in step 1 is no longer necessary. the client app can send the following request either in browser or in native library (js or native code). The second request is a POST request to tokenEndpoint, the post body includes
grandType (required)
client_ID (required)
code (required)
redirect url (required if redirect url is included in the initial authorization request)
scope

request sample:

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

4. Authorization server will return an access token and refresh token (in JSON string format) in the response.

Sample:

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

5. Client app can send the resource request to resource server by presenting the access token into request 's "Authorization" head as a "bearer". 

Header["Authorization"] = "Bearer " + access_token;
example:

   Authorization: Bearer mF_9.B5f-4.1JqM

The resource server must validate the access token and be sure the resource is covered by the scope.

6. In case the access token is expired, it can be refreshed by using refresh token. To do so, sending the request to token access endpoint, with the below parameter
grand_type (required, value must be "refresh_token")
refresh_token (required)
scope (optional)

example:

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

The access token will be returned in the response.

Reference:
https://tools.ietf.org/html/rfc6749