Monday, September 11, 2017

Sequential Display Using Semaphore and Wait Notify.

Semaphore:

A counting semaphore. Conceptually, a semaphore maintains a set of permits. Each acquire() blocks if necessary until a permit is available, and then takes it. Each release() adds a permit, potentially releasing a blocking acquirer. However, no actual permit objects are used; the Semaphore just keeps a count of the number available and acts accordingly.
Semaphores are often used to restrict the number of threads than can access some (physical or logical) resource. For example, here is a class that uses a semaphore to control access to a pool of items:

Semaphores have no notion of ownership, so they cannot be reentrant, although as many permits as are available may be acquired. That means a thread needs to block when it encounters a value of 0, until someone increments the semaphore.


// Sequential Display Using Semaphore 

package com.corejavarevise;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;


/**
 * Sequencial Printing Using Semaphore
 * @author S730175
 *
 */
public class PrintSequenceWithSemaphore {

public static void main(String[] args) {
// TODO Auto-generated method stub
final PrintSequence printSequence = new PrintSequenceWithSemaphore.PrintSequence();
ExecutorService executors = Executors.newFixedThreadPool(3);
executors.execute(new Runnable() {

@Override
public void run() {
printSequence.printOne();
}
});
executors.execute(new Runnable() {

@Override
public void run() {
printSequence.printTwo();
}
});
executors.execute(new Runnable() {

@Override
public void run() {
printSequence.printThree();
}
});

}

static class PrintSequence {
volatile int i = 0;
Semaphore sm1 = new Semaphore(1);
Semaphore sm2 = new Semaphore(0);
Semaphore sm3 = new Semaphore(0);

public void printOne() {
while(i<100) {
try {
sm1.acquire();
System.out.println(++i);
sm2.release();

} catch (InterruptedException e) {

}
}
}

public void printTwo() {
while(i<100) {
try {
sm2.acquire();
System.out.println(++i);
sm3.release();

} catch (InterruptedException e) {

}
}
}

public void printThree() {
while(i<100) {
try {
sm3.acquire();
System.out.println(++i);
sm1.release();

} catch(InterruptedException e) {

}
}
}


}

}



/////////////////// Sequential Display Using Wait Notify //////////////////////


package com.corejavarevise.threadrevise;

public class SequenceDisplay {

/**
 *
 */
static Object monitor = new Object();

static boolean one = true;
static boolean two = false;
static boolean three = false;

public static void main(String[] args) {
Thread t4 = new Thread("4"){
public void run() {
System.out.println("I am thread 4");
}
};
t4.start();

Thread t1 = new Thread(new SequenceDisplayImpl(1));
 Thread t2 = new Thread(new SequenceDisplayImpl(2));
 Thread t3 = new Thread(new SequenceDisplayImpl(3));

 Thread.currentThread().getName();
 t1.start();
 t2.start();
 t3.start();

}

static class SequenceDisplayImpl implements Runnable {

 int threadId;

 SequenceDisplayImpl(int threadId) {
  this.threadId = threadId;
 }

 public void run() {
  print();
 }

 private void print() {
  try {
   while (true) {
    Thread.sleep(500);
    synchronized (monitor) {
     if (1 == threadId) {
      if (!one) {
       monitor.wait();
      } else {
       System.out.print(threadId + " ");
       one = false;
       two = true;
       three = false;
       monitor.notifyAll();
      }
     }
     if (2 == threadId) {
      if (!two) {
       monitor.wait();
      } else {
       System.out.print(threadId + " ");
       one = false;
       two = false;
       three = true;
       monitor.notifyAll();
      }
     }
     if (3 == threadId) {
      if (!three) {
       monitor.wait();
      } else {
       System.out.print(threadId + " ");
       one = true;
       two = false;
       three = false;
       monitor.notifyAll();
      }
     }
    }
   }
  } catch (InterruptedException e) {
   e.printStackTrace();
  }

 }

}

}

<a href="https://www.sejda.com/mgl/compress-pdf-onlineCompress PDF">Compress PDF</a>

Thursday, January 12, 2017

Using JWT with Spring Security OAuth2


I recently implemented OAuth2 with JWT in Spring Restful Services.

Code implementation can be found from below git repository.
https://github.com/saurabh-ranu/ShareYourViewsServices


OAUTH2.0 Specification: 

Introduction

   In the traditional client-server authentication model, the client
   requests an access-restricted resource (protected resource) on the
   server by authenticating with the server using the resource owner's
   credentials.  In order to provide third-party applications access to
   restricted resources, the resource owner shares its credentials with
   the third party.  This creates several problems and limitations:
 
   o  Third-party applications are required to store the resource
      owner's credentials for future use, typically a password in
      clear-text.
 
   o  Servers are required to support password authentication, despite
      the security weaknesses inherent in passwords.
 
   o  Third-party applications gain overly broad access to the resource
      owner's protected resources, leaving resource owners without any
      ability to restrict duration or access to a limited subset of
      resources.
 
   o  Resource owners cannot revoke access to an individual third party
      without revoking access to all third parties, and must do so by
      changing the third party's password.
 
 
   o  Compromise of any third-party application results in compromise of
      the end-user's password and all of the data protected by that
      password.
 
   OAuth addresses these issues by introducing an authorization layer
   and separating the role of the client from that of the resource
   owner.  In OAuth, the client requests access to resources controlled
   by the resource owner and hosted by the resource server, and is
   issued a different set of credentials than those of the resource
   owner.
 
   Instead of using the resource owner's credentials to access protected
   resources, the client obtains an access token -- a string denoting a
   specific scope, lifetime, and other access attributes.  Access tokens
   are issued to third-party clients by an authorization server with the
   approval of the resource owner.  The client uses the access token to
   access the protected resources hosted by the resource server.
 

  Roles

   OAuth defines four roles:
 
   resource owner
      An entity capable of granting access to a protected resource.
      When the resource owner is a person, it is referred to as an
      end-user.
 
   resource server
      The server hosting the protected resources, capable of accepting
      and responding to protected resource requests using access tokens.
 
   client
      An application making protected resource requests on behalf of the
      resource owner and with its authorization.  The term "client" does
      not imply any particular implementation characteristics (e.g.,
      whether the application executes on a server, a desktop, or other
      devices).
 
   authorization server
      The server issuing access tokens to the client after successfully
      authenticating the resource owner and obtaining authorization.
 
   The interaction between the authorization server and resource server
   is beyond the scope of this specification.  The authorization server
   may be the same server as the resource server or a separate entity.
   A single authorization server may issue access tokens accepted by
   multiple resource servers.
 

Protocol Flow

 
     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner(or End User)     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |        (Credentials)          +
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
 
                     Figure 1: Abstract Protocol Flow
 
   The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
   interaction between the four roles and includes the following steps:
 
   (A)  The client requests authorization from the resource owner.  The
        authorization request can be made directly to the resource owner
        (as shown), or preferably indirectly via the authorization
        server as an intermediary.
 
   (B)  The client receives an authorization grant, which is a
        credential representing the resource owner's authorization,
        expressed using one of four grant types defined in this
        specification or using an extension grant type.  The
        authorization grant type depends on the method used by the
        client to request authorization and the types supported by the
        authorization server.
 
   (C)  The client requests an access token by authenticating with the
        authorization server and presenting the authorization grant.
 
   (D)  The authorization server authenticates the client and validates
        the authorization grant, and if valid, issues an access token.
 

Authorization Grant

   An authorization grant is a credential representing the resource
   owner's authorization (to access its protected resources) used by the
   client to obtain an access token.  This specification defines four
   grant types -- authorization code, implicit, resource owner password
   credentials, and client credentials -- as well as an extensibility
   mechanism for defining additional types.
 

1.  Authorization Code

   The authorization code is obtained by using an authorization server
   as an intermediary between the client and resource owner.  Instead of
   requesting authorization directly from the resource owner, the client
   directs the resource owner to an authorization server (via its
   user-agent as defined in [RFC2616]), which in turn directs the
   resource owner back to the client with the authorization code.
 
   Before directing the resource owner back to the client with the
   authorization code, the authorization server authenticates the
   resource owner and obtains authorization.  Because the resource owner
   only authenticates with the authorization server, the resource
   owner's credentials are never shared with the client.
 
   The authorization code provides a few important security benefits,
   such as the ability to authenticate the client, as well as the
   transmission of the access token directly to the client without
   passing it through the resource owner's user-agent and potentially
   exposing it to others, including the resource owner.
 
 
   The authorization code grant type is used to obtain both access
   tokens and refresh tokens and is optimized for confidential clients.
   Since this is a redirection-based flow, the client must be capable of
   interacting with the resource owner's user-agent (typically a web
   browser) and capable of receiving incoming requests (via redirection)
   from the authorization server.
 
     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)
The flow illustrated in Figure 3 includes the following steps:
 
   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).
 
   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.
 
   (C)  Assuming the resource owner grants access, the authorization
        server redirects the user-agent back to the client using the
        redirection URI provided earlier (in the request or during
        client registration).  The redirection URI includes an
        authorization code and any local state provided by the client
        earlier.
 
   (D)  The client requests an access token from the authorization
        server's token endpoint by including the authorization code
        received in the previous step.  When making the request, the
        client authenticates with the authorization server.  The client
        includes the redirection URI used to obtain the authorization
        code for verification.
 
   (E)  The authorization server authenticates the client, validates the
        authorization code, and ensures that the redirection URI
        received matches the URI used to redirect the client in
        step (C).  If valid, the authorization server responds back with
        an access token and, optionally, a refresh token.
 
 2.  Implicit
 
 
   The implicit grant is a simplified authorization code flow optimized
   for clients implemented in a browser using a scripting language such
   as JavaScript.  In the implicit flow, instead of issuing the client
   an authorization code, the client is issued an access token directly
  (as the result of the resource owner authorization).  The grant type
   is implicit, as no intermediate credentials (such as an authorization
   code) are issued (and later used to obtain an access token).
 
   When issuing an access token during the implicit grant flow, the
   authorization server does not authenticate the client.  In some
   cases, the client identity can be verified via the redirection URI
   used to deliver the access token to the client.  The access token may
   be exposed to the resource owner or other applications with access to
   the resource owner's user-agent.
 
 
 
 
 
+----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+
 

   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).
 
   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.
 
   (C)  Assuming the resource owner grants access, the authorization
        server redirects the user-agent back to the client using the
        redirection URI provided earlier.  The redirection URI includes
        the access token in the URI fragment.
 
   (D)  The user-agent follows the redirection instructions by making a
        request to the web-hosted client resource (which does not
        include the fragment per [RFC2616]).  The user-agent retains the
        fragment information locally.
 
   (E)  The web-hosted client resource returns a web page (typically an
        HTML document with an embedded script) capable of accessing the
        full redirection URI including the fragment retained by the
        user-agent, and extracting the access token (and other
        parameters) contained in the fragment.
 
   (F)  The user-agent executes the script provided by the web-hosted
        client resource locally, which extracts the access token.
 
   (G)  The user-agent passes the access token to the client.

3.  Resource Owner Password Credentials

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access

   token.  The credentials should only be used when there is a high
   degree of trust between the resource owner and the client (e.g., the
   client is part of the device operating system or a highly privileged
   application), and when other authorization grant types are not
   available (such as an authorization code).
 
   The resource owner password credentials grant type is suitable in
   cases where the resource owner has a trust relationship with the
   client, such as the device operating system or a highly privileged
   application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.
 
   This grant type is suitable for clients capable of obtaining the
   resource owner's credentials (username and password, typically using
   an interactive form).  It is also used to migrate existing clients
   using direct authentication schemes such as HTTP Basic or Digest
   authentication to OAuth by converting the stored credentials to an
   access token.
 
     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+
 
The flow illustrated in Figure includes the following steps:
 
   (A)  The resource owner provides the client with its username and
        password.
 
   (B)  The client requests an access token from the authorization
        server's token endpoint by including the credentials received
        from the resource owner.  When making the request, the client
        authenticates with the authorization server.
 
   (C)  The authorization server authenticates the client and validates
        the resource owner credentials, and if valid, issues an access
        token.
 
 4. Client Credentials
 
   The client credentials (or other forms of client authentication) can
   be used as an authorization grant when the authorization scope is
   limited to the protected resources under the control of the client,
   or to protected resources previously arranged with the authorization
   server.  Client credentials are used as an authorization grant
   typically when the client is acting on its own behalf (the client is
   also the resource owner) or is requesting access to protected
   resources based on an authorization previously arranged with the
   authorization server.
 
     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+
 
                     Figure : Client Credentials Flow
 
   The flow illustrated in Figure 6 includes the following steps:
 
   (A)  The client authenticates with the authorization server and
        requests an access token from the token endpoint.
 
   (B)  The authorization server authenticates the client, and if valid,
        issues an access token.
 

   Access Token

  Access tokens are credentials used to access protected resources. An
   access token is a string representing an authorization issued to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
 
   The token may denote an identifier used to retrieve the authorization
   information or may self-contain the authorization information in a
   verifiable manner (i.e., a token string consisting of some data and a
   signature).  Additional authentication credentials, which are beyond
   the scope of this specification, may be required in order for the
   client to use a token.

Refresh Token

  Refresh tokens are credentials used to obtain access tokens.  Refresh
   tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner).  Issuing a refresh token is optional at the discretion of the
   authorization server.  If the authorization server issues a refresh
   token, it is included when issuing an access token (i.e., step (D) in
   Figure 1).
 



  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+
 
 
 

Client Registration

  Before initiating the protocol, the client registers with the
   authorization server.  The means through which the client registers
   with the authorization server are beyond the scope of this
   specification but typically involve end-user interaction with an HTML
   registration form.
 
        When registering a client, the client developer SHALL:
 
   o  specify the client type.
 
   o  provide its client redirection URIs.
 
   o  include any other information required by the authorization server
      (e.g., application name, website, description, logo image, the
      acceptance of legal terms).
 

Client Types

  OAuth defines two client types, based on their ability to
   authenticate securely with the authorization server (i.e., ability to
   maintain the confidentiality of their client credentials):
 
   confidential
      Clients capable of maintaining the confidentiality of their
      credentials (e.g., client implemented on a secure server with
      restricted access to the client credentials), or capable of secure
      client authentication using other means.
 
   public
      Clients incapable of maintaining the confidentiality of their
      credentials (e.g., clients executing on the device used by the
      resource owner, such as an installed native application or a web
      browser-based application), and incapable of secure client
      authentication via any other means.
 
        This specification has been designed around the following client
        profiles:
 
web application
      A web application is a confidential client running on a web
      server.  Resource owners access the client via an HTML user
      interface rendered in a user-agent on the device used by the
      resource owner.  The client credentials as well as any access
      token issued to the client are stored on the web server and are
      not exposed to or accessible by the resource owner.
 
   user-agent-based application
      A user-agent-based application is a public client in which the
      client code is downloaded from a web server and executes within a
      user-agent (e.g., web browser) on the device used by the resource
      owner.  Protocol data and credentials are easily accessible (and
      often visible) to the resource owner.  Since such applications
      reside within the user-agent, they can make seamless use of the
      user-agent capabilities when requesting authorization.
 
   native application
      A native application is a public client installed and executed on
      the device used by the resource owner.  Protocol data and
      credentials are accessible to the resource owner.  It is assumed
      that any client authentication credentials included in the
      application can be extracted.  On the other hand, dynamically
      issued credentials such as access tokens or refresh tokens can
      receive an acceptable level of protection.  At a minimum, these
      credentials are protected from hostile servers with which the
      application may interact.  On some platforms, these credentials
      might be protected from other applications residing on the same
      device.
  

Client Identifier

   The authorization server issues the registered client a client
   identifier -- a unique string representing the registration
   information provided by the client.  The client identifier is not a
   secret; it is exposed to the resource owner and MUST NOT be used
   alone for client authentication.  The client identifier is unique to
   the authorization server.
 

Client Authentication

   If the client type is confidential, the client and authorization
   server establish a client authentication method suitable for the
   security requirements of the authorization server.  The authorization
   server MAY accept any form of client authentication meeting its
   security requirements.
 

Client Password

   Clients in possession of a client password MAY use the HTTP Basic
   authentication scheme

Alternatively, the authorization server MAY support including the
   client credentials in the request-body using the following
   parameters:
 
   client_id
         REQUIRED.  The client identifier issued to the client during
         the registration process.
 
   client_secret
         REQUIRED.  The client secret.  The client MAY omit the
         parameter if the client secret is an empty string.

3. Protocol Endpoints

The authorization process utilizes two authorization server endpoints
   (HTTP resources):
 
   o  Authorization endpoint - used by the client to obtain
      authorization from the resource owner via user-agent redirection.
 
   o  Token endpoint - used by the client to exchange an authorization
      grant for an access token, typically with client authentication.

Authorization Endpoint

   The authorization endpoint is used to interact with the resource
   owner and obtain an authorization grant.  The authorization server
   MUST first verify the identity of the resource owner.  The way in
   which the authorization server authenticates the resource owner
   (e.g., username and password login, session cookies) is beyond the
   scope of this specification.

Token Endpoint

   The token endpoint is used by the client to obtain an access token by
   presenting its authorization grant or refresh token.  The token
   endpoint is used with every authorization grant except for the
   implicit grant type (since an access token is issued directly).
 
   The means through which the client obtains the location of the token
   endpoint are beyond the scope of this specification, but the location
   is typically provided in the service documentation.


The client MUST use the HTTP "POST" method when making access token
   requests. 

Client Authentication

   Confidential clients or other clients issued client credentials MUST
   authenticate with the authorization server when making requests to the token endpoint.  Client
   authentication is used for:
 
   o  Enforcing the binding of refresh tokens and authorization codes to
      the client they were issued to.  Client authentication is critical
      when an authorization code is transmitted to the redirection
      endpoint over an insecure channel or when the redirection URI has
      not been registered in full.
 
   o  Recovering from a compromised client by disabling the client or
      changing its credentials, thus preventing an attacker from abusing
      stolen refresh tokens.  Changing a single set of client
      credentials is significantly faster than revoking an entire set of
      refresh tokens.
 
   o  Implementing authentication management best practices, which
      require periodic credential rotation.  Rotation of an entire set
      of refresh tokens can be challenging, while rotation of a single
      set of client credentials is significantly easier.

Security Considerations


   As a flexible and extensible framework, OAuth's security
   considerations depend on many factors.  The following sections
   provide implementers with security guidelines focused on the three
   client profiles described in Section 2.1: web application,
   user-agent-based application, and native application.
 
   A comprehensive OAuth security model and analysis, as well as
   background for the protocol design, is provided by
   [OAuth-THREATMODEL].
 

 

1.   Client Authentication

 
 
   The authorization server establishes client credentials with web
   application clients for the purpose of client authentication.  The
   authorization server is encouraged to consider stronger client
   authentication means than a client password.  Web application clients
   MUST ensure confidentiality of client passwords and other client
   credentials.

2.  Client Impersonation

   A malicious client can impersonate another client and obtain access
   to protected resources if the impersonated client fails to, or is
   unable to, keep its client credentials confidential.
 
   The authorization server MUST authenticate the client whenever
   possible.  If the authorization server cannot authenticate the client
   due to the client's nature, the authorization server MUST require the
   registration of any redirection URI used for receiving authorization
   responses and SHOULD utilize other means to protect resource owners
   from such potentially malicious clients.  For example, the
   authorization server can engage the resource owner to assist in
   identifying the client and its origin.

Access Tokens

   Access token credentials (as well as any confidential access token
   attributes) MUST be kept confidential in transit and storage, and
   only shared among the authorization server, the resource servers the
   access token is valid for, and the client to whom the access token is
   issued.  
 
Access token credentials MUST only be transmitted using TLS
When using the implicit grant type, the access token is transmitted
   in the URI fragment, which can expose it to unauthorized parties.
 
   The authorization server MUST ensure that access tokens cannot be
   generated, modified, or guessed to produce valid access tokens by


   unauthorized parties.


I will post further detail soon.
For any query you can reach me at saurabh.ranu@hotmail.com