Fonteva supports three different Authentication Types for outgoing API calls. 

  • OAuth 2.0 

  • OAuth 1A 

  • Basic  

  • None 

 

All incoming API calls are required to meet OAuth2 specification ONLY.  

 

Basic Authentication Workflow 

 


Basic Authentication relies on the user's username and password for the External Application. The user's username and password are encoded using Base64 encryption and sent to the External Application for authentication. 

  

Understanding OAuth 1A and 2 


OAuth is an open protocol to allow secure API authorization in a standardized way from Fonteva applications. This allows users to authorize applications to access Fonteva resources without revealing passwords or other application credentials. This framework also allows applications to directly authenticate access to the same resources without accessing end user credentials. 

  

OAuth allows a client application to access your data on a limited basis. Restricted access is granted using tokens issued by an authorization server in response to the access permissions you grant. 

  

There are four roles in OAuth specifications: 

  • Resource owner: The user who authorizes their Fonteva application to access their information on the External Application.

  • Client: The Fonteva application.

  • Resource Server: The REST API.

  • Authorization Server: The specified server that will authenticate the user’s credentials.

  

OAuth typically grants access through the following steps: 

  1. Fonteva requests authorization to access service resources from the user. 

  2. If the user authorized the request, Fonteva receives an Authorization Grant. 

  3. Fonteva requests an access token from the External Application (API) by presenting authentication of its identity (Client ID and Client Secret) and the Authorization Grant.

  4. If the identity and Authorization Grant are valid, the Authorization Server issues an access token to the application. Authorization is complete.

  5. Fonteva requests the resource(s) from the resource server (external application or database) and presents the Access Token.

  6. Once the Access Token is validated, the Resource Server sends the resource(s) to Fonteva.

  

OAuth Workflow in Fonteva 


[Enter] the following data on the Connect tab: 

  • Client ID – The publicly exposed string used to identify the External Application.

  • Client Secret – The private string used to authenticate the identity of your Fonteva application to the External Application. 

  • Scope – The scope of the access granted by the External Application.

  • Login Dialog URL – The callback URL. The user is redirected back to this URL when authorization is obtained. 

  • Authorization Request URL – The URL used by the External Application to request an authorization token.

  • HTTP Method to Get Token – Choose the following from the menu: 

    • GET 
    • POST 

 

  • Some Authorization Servers will require a specific Scope. If you omit the Scope field, the Authorization Server either processes the request using a pre-defined default or fails the request 

  • The Authorization Server may either fully or partially ignore the Scope depending on server policy or the resource owner's parameters 

  

If you choose OAuth2: 

 


OAuth2 supports Refresh Token. For example, if the Authorization Server indicates that the Client Access Token has expired, Fonteva automatically refreshes the Access Token and retries the call. If the call fails, Fonteva logs the exception. 

  

None Workflow in Fonteva 


If the external application or database has a public API, choose None. You will be directed to the Deploy tab.