Our SaaS cloud platform allows you to create applications that interact with the API using a unique 'access token'. Each application has its own set of permissions, which are determined by combining 'Roles' (what actions can be performed) and 'Scopes' (where those actions can be performed).
You can create different types of applications depending on your needs. Applications can be set up to render for a specific domain name, to interact with the platform as a headless API, or to be protected by a passcode.
Domain-Based Applications
If you're creating a website or a browser-based application, you can configure your application to render an interface for a specific domain name. This ties your application to that particular domain, making it accessible to users who visit that URL, and the configured Interface will be brought to life with the application's access token.
Passcode-Protected Applications
For an added layer of security, you can restrict access to your application by setting a passcode. When a passcode is configured, any visitor to the domain name will be required to enter the correct passcode before they can access the application and use it's token. This is helpful if wanting to maybe create a preview link or a kiosk app or a web app that can be shared where you don't need the complexity of individual users logging in but you do want an extra layer of security.
Headless API Applications
Not all applications need to be associated with a domain name. If you're building a tool that interacts with the platform purely through the API, without a user-facing component, you can create an application without specifying a domain. In this case, the application serves as a way to manage an access token for making API requests.
Unlike user access tokens that expire, an application's access token is permanent. This ensures that public websites and search engines can always access and index content without broken links.
Permissions are set by combining Roles and Scopes. For example:
'Public Website Visitor' Role: Can view images, articles, and comments
'Logged In User' Role: Can create, edit, and delete their own comments within the 'Public' Scope
You can define what roles, scopes, and permissions an application has. For instance:
Public Website Visitor (role) in 'Website' (scope)
This means the application can act as a Public Website Visitor within the 'Website' Scope when using the API.
You can also set User Permission Sets for an application. For example:
Logged In User (Role) in 'Website' (scope)
This means any user who logs into the application will get a token with the application's permissions plus the user-specific permissions.
So in this case, your website could show images and content to everyone, but only let logged-in users write comments.
Users can also have individual permissions or 'Access Passes', which get combined with the Application's token for their session.
Putting It All Together
By combining these application types with the access control features discussed earlier (Roles, Scopes, and Permission Sets), you can create powerful and flexible configurations to suit your specific needs. For example:
A public-facing website could be set up as a domain-based application, with different roles for anonymous visitors and logged-in users.
An internal tool for your team could be a headless API application, with specific roles and permissions for each team member.
A client portal could be a domain-based application protected by a passcode, ensuring that only authorized clients can access their files and information.
The possibilities are endless! Our platform provides you with the tools to create secure, customized access control systems for any type of application you need.