Secure Mobile Access using Ping Federate OAuth server

      OAuth 2.0 is explicitly designed to support a variety of different client types, which access REST APIs. This includes both applications running on web servers within the enterprise calling out to the Cloud as well as applications running on employee or customer mobile devices. OAuth supports this variety of client types by defining multiple mechanisms for ‘getting a token’ where the different mechanisms acknowledge the client type constraints.

 

The below image is a scenario which briefly shows the authentication flow carried to secure and share your information (present at the OAuth Server) with the resource server (third party application) without sharing the login credentials. There are various grant types within OAuth 2.0 with very small differences between them. This site will articulate the steps for the “Authorization Code” grant type.

        The below sequence diagram shows how Applications/Processes and the Resource Owner interact with one another to share information and  communicate information.

• Authorization Server (AS): AS acts an entity which creates and shares tokens (containing user or Resource Owner (RO) information) with client applications.  These tokens refer to the user information typically stored on the AS which are used by the Resource Servers(RS) to gain user information and then make a decision on providing access to the protected resources.

• Resource Servers(RS): RS os configured with the AS such that when a client application presents tokens, it can use validate this token against the AS endpoint and derive the necessary and configured attributes.

• Resource Owner (RO): Typically. this role is played by a user who wants to access a protected resource on a third party Resource Server. The RO authorizes the client/mobile application (CA) to gain access tokens from the Authorization Server (AS) on behalf of the user and present  these tokens to the third party Resource Server (RS).

• Mobile/Client Application (CA): The CA is configured with the AS such that the user can authorize it to gain tokens on behalf of the user. The CA is a registered application which is configured to redirect the RO/user to the AS login page whenever the user makes an access to the protected resource on the Resource Server (RS).

How it works:

1. A Resource Owner (RO)/User via a client/mobile application makes an access to a resource on the third party Resourse Server (RS). Here, both the client/mobile application and the RS are protected using OAuth 2.0 protocol feature available in Ping Identity which acts as an Authorization Server. Since, there is no valid information about the user at the Resource Server when he accesses the protected resource for the first time, the RS redirects the user/client application to make a token request to the configured Authorization Server (AS) (Ping Identity OAuth endpoint) for the user to give consent to share his information.
2. The AS validate the client application against the token request parameters and  presents a login page to the RO to authenticate himself. Once he logs in successfully, the AS presents a page detailing out the information that is going to be shared with the third party RS on his consent.
3. After the RO provides consent, the AS server presents an access token which the client/mobile application can present to the RS to access the user information. If the user does not provide the consent, an error is shown to the user and the desired resource cannot be accessed.
4. The RS uses this access token and makes a call bacb to the AS to get the user information. Once the token is validated by the OS along with the credential provided by the RS to authenticate itslef, the RS is provided with the shared information about the user and the RS then redirects the user to the earlier accessed protected resource.

For general setup and configuration, refer to the following URLs: