Applications overview
Connect your applications to SecureAuth to control who can access them and how users authenticate.
What is an application?
In SecureAuth, an application represents any software that your users access - whether it's a web portal, mobile app, desktop tool, or third-party service.
When you add an application to SecureAuth, you're connecting it so SecureAuth can control access. This allows you to:
- Control who can access the application
- Enforce authentication requirements (passwords, MFA, SSO)
- Pass user information to the application
- Monitor and audit access
SecureAuth works with two main types of applications:
-
Clients - Applications where users log in. These request authentication from SecureAuth (like your employee portal or mobile app).
-
Services - Backend APIs and microservices that need access control. These validate access tokens to protect resources.
Common scenarios
Here are typical situations where you'd add applications to SecureAuth:
Your employees need to access internal tools
Add your employee portal, HR system, or project management tools as applications. Control access based on department, role, or location.
Customers log into your web or mobile app
Connect your customer-facing applications so users can create accounts, log in, and access their data securely.
You're using third-party SaaS applications
Connect services like Salesforce, Office 365, or Workday so employees can use single sign-on instead of managing separate passwords.
Your backend services need to communicate
Set up service-to-service authentication so your APIs can verify requests from your microservices or scheduled jobs.
Choosing the right application type
SecureAuth configures security settings based on your application type. Choose the type that matches how your application works:
Single-page application (SPA)
What it is: A modern web application that your developers built, typically used for employee dashboards or customer portals. If you're unsure, ask your development team if the app is a "single-page application" or built with frameworks like React or Vue.
When to use:
- Employee dashboards that load in the browser
- Customer portals where users manage their accounts
- Web-based tools that feel like desktop apps
Examples: Customer account portal, employee self-service dashboard, interactive data visualization tool
Add a single-page application →
Server-side web application
What it is: A traditional web application where your server handles user authentication and manages secure credentials. If you're unsure, ask your development team if the app uses server-side authentication or is built with Node.js, .NET, or Java.
When to use:
- You control both the front-end and back-end
- Your application needs to call APIs on behalf of users
- You want to keep authentication credentials secure on the server
Examples: Internal employee portal, customer support ticketing system, content management system
Add a server-side web application →
Mobile or desktop application
What it is: A native application that users install on their phones, tablets, or computers (not accessed through a web browser).
When to use:
- iOS or Android mobile apps
- Windows, Mac, or Linux desktop applications
- Apps that run on user devices rather than in a browser
Examples: Mobile banking app, field service technician app, desktop collaboration tool
Add a native or mobile application →
Service application (machine-to-machine)
What it is: Automated systems that need to access your APIs without a person logging in. Common for scheduled tasks, integrations between systems, or services running in the background.
When to use:
- Backend services calling your APIs
- Scheduled jobs that sync data between systems
- Microservices that need to authenticate with each other
- CLI tools or scripts that access protected resources
Examples: Nightly data sync job, payment processing service, monitoring system that queries APIs
Add a machine-to-machine application →
SAML service provider
What it is: Applications that use SAML for authentication, common in enterprise environments.
When to use:
- Third-party SaaS applications your employees use
- Legacy enterprise applications that require SAML
- Partner applications that need federated authentication
- The application only supports SAML (not newer authentication methods)
Examples: Salesforce, Workday, legacy HR system, partner portal
Technical reference
For technical teams: SecureAuth applies different security settings based on application type:
| Type | Grant types | Response types | Auth method | Notes |
|---|---|---|---|---|
| Single Page App | Authorization Code Flow | Code, Token, ID | None | Public client with no client secret |
| Server-Side Web App | Authorization Code Flow | Code, Token | client_secret_post | Private client |
| Mobile/Desktop App | Authorization Code Flow | Code, Token, ID | None | Public client with no client secret |
| Service App | Client Credentials Flow | Token | client_secret_post | Private client |
| SAML Service Provider | SAML 2.0 | SAML assertions | Certificate-based | Enterprise SSO |
| Single Page (Legacy) | Implicit Flow | Token | None | Public client with no client secret |
Next steps
After adding your application:
- Restrict access with user policies to control who can use the application
- Configure OAuth settings for advanced authentication scenarios
- Set up identity providers to enable SSO with Google, Microsoft, or other providers
- Require MFA for sensitive applications