Application registration is a necessary requirement for accessing and operating different SmartCommunity APIs. The registration is possible through the SmartCommunity Developer Console.

Before accessing the console, the developer should be authenticated. Once signed in, the user see the empty console where it is possible to create an app:

To create an app, it is enough to select the application name. Note that the application name should be unique, otherwise the application will not be created.

A newly created app is provided with the set of generated attributes (client_id, client_secret, client_secret_mobile) present on the overview tab.

To start using the client in order to access the SmartCommunity resources, the following steps should be performed: configure the authorization methods and configure application permissions.

On the settings page it is necessary to select which methods will be used by the client for user authorization. Specifically, it is necessary to select

• server-side access checkbox and a valid redirect Web Server URL in case of authorization code flow;
• browser access checkbox and a valid redirect Web Server URL in case of implicit flow;
• native app access in case of native mobile apps.

On the settings page it is necessary to select which identity providers will be used for the user authentication. That is, which authentication links will be available for the user when she is prompted for the authentication and authorization. Specifically, it is necessary to select one or more identity providers among those supported at the platform level.

Please note that not all the identity providers are immediately available, some of them (e.g., UniTN or FBK) are available only to explicitly authorized clients. Once approved, those identity providers become available.

The second configuration step refers to specifying which resources the application wants to access.

The model of permissions in SmartCommunity is parametric. This means, for instance, that some services may allow for declaring new specific scopes and limit the access to those scopes only. For example, a file storage service, allows an application to declare its own storage “folder” and restrict the access to the user files stored in that folder.

Another important aspect is that the resources are divided into the ones owned by (or available to) the user (i.e., user resources) and those that are available to an app without involving a user (i.e., client resources). For example, the user files are of the first type, while the file storage configuration resource is of the second type.

It is also important to know that some of the resources are not immediately available to the application once registered. Their access may be subject of the external approval by the data providers through some additional procedure. Once such a procedure is accomplished, the administrator will unblock the access to the resource by the application.

At the Permissions tab the developer may specify which services and which resources the application will require. At the “Available Resources” section it is possible to choose among already existing resources, while at the “Own Resources” section it is possible to create new specific scopes for different services, which will lead to the creation of new resources.

As already mentioned, some of the resources will not be immediately assigned and will require explicit approval. Below, for example the 'SmartCommunity.profile.basicprofile.me' permission is immediately assigned, while 'SmartCommunity.profile.basicprofile.all' (access to all SmartCommunity user profiles) is pending approval.

The developer may additionally control the access to the new specific scopes registered by the app. The levels of access are:

• Current app: only this app may access the resources entailed by this scope.
• Owned apps: only the apps of this developer may access the resources entailed by this scope.
• Public: access is allowed for all the apps.

In the following example access to the files scoped to the newly created resource scope 'testappfolder' is restricted to the app itself only.

The resources entailed by the own resource scopes are automatically asigned to the application.

Once the client app is registered and configured, it is possible to perform authorization and access the services. To facilitate the testing phase, the developer console provides means to generate both the user and the client access tokens: in the 'Overview' tab the 'Get client credentials flow token' link allows for generating the client access token and the 'Get implicit flow token' link allows for generating the user access token associated to the developer's account.