Kloudless engineers commonly field questions on how users connect their cloud accounts to Kloudless apps and how the process works across the different authentication schemes cloud providers use. The Kloudless API’s abstraction layer begins right from authentication; Kloudless provides a uniform OAuth 2.0 flow to authenticate end-user accounts regardless of which upstream third-party cloud provider the account belongs to.
As a result, we’ve seen our fair share of authentication schemes, ranging from excellent implementations of standardized protocols to quirky custom mechanisms to grant access to end-user data.
While detailing all the differences between the forms of authentication we encounter is beyond the scope of this blog post, we will highlight the different approaches and how Kloudless supports them via our unified authentication flow:
- OAuth 2.0
- JWT authentication
- Basic authentication with passwords or keys
Apps primarily use Kloudless to connect to repositories of user-generated content. Whether it’s Salesforce, Google Drive, or Outlook Calendar, users create the data that is available in the service. This presents a perfect scenario for cloud providers to use OAuth 2.0 to grant access to user data. That is in fact the case—OAuth 2.0 is the most common authentication scheme we see to connect to cloud SaaS apps. We also rarely see the deprecated OAuth 1.0 flow in use any longer.
The OAuth 2.0 authorization code grant flow first involves redirecting users to the authorization server to grant an app access to their data. The OAuth provider then redirects the user back to their app with a code to request a secret Bearer token to access the cloud app’s API with.
Kloudless acts as a middle layer in the flow described above. Apps redirect users to the Kloudless OAuth flow instead, which immediately redirects the user to appropriate third-party OAuth flow or other authentication scheme. Similarly, Kloudless receives the code described above, stores the token information obtained from the exchange, and returns a code of its own to the developer’s app. The developer’s app then retrieves its own Bearer token to access the Kloudless API with.
Some of the complexities during this process are described below.
Keeping tokens active
OAuth 2.0 bearer tokens may expire! We commonly see access tokens only valid for an hour. In that case, apps can use a separate refresh token to obtain a new set of tokens. While Kloudless’ own tokens don’t expire due to additional security checks on each API request, Kloudless takes steps to keep third-party tokens active and refreshed behind the scenes. This simplifies most apps’ API request authorization process as it avoids apps needing to periodically refresh tokens.
Data access scope
The OAuth 2.0 protocol supports including a
scope that indicates the level of access to data. Kloudless also supports both Kloudless-level scopes, as well as custom third-party scopes nested within a Kloudless scope (docs).
Self-hosted servers and private tenants such as ones running Adobe Experience Manager, SugarCRM, or ServiceNow, require OAuth to be set up on a per-server basis by the administrator of the server. This requires an extra field during the authentication process that accepts the hostname of the server to connect to.
Server-to-server JWT authentication
Services such as G Suite, Office 365, and Box Enterprise enable admins to grant org-wide access to data on all individual user accounts in the tenant. This usually requires the developer app to generate an RSA key-pair and provide the public key to the cloud app or directly to the admin in some manner to add to their tenant. The app then generates a JWT assertion to obtain an access token to use to access individual user accounts.
Basic authentication is the simplest form of authentication of the ones mentioned above. However, we highly discourage it if alternatives are available due to needing to store users’ passwords. Kloudless encrypts and stores user credentials if needed, or if the service only offers key-based authentication (such as Amazon S3). In several cases, we’ve found that apps make it possible to exchange the username and password for a Bearer token, using the OAuth 2.0 resource owner password credentials flow, to avoid having to actually store the password for future access.
The Kloudless unified authentication flow wraps the third-party authentication schemes mentioned above to simplify the process of connecting user accounts across different apps. Check out our Authentication docs and try out our Authenticator JS library to learn more!