Skip to main content

Common use cases for authentication

These examples illustrate how you can leverage auth providers to enforce authentication policies, securely manage access for various user groups (from employees and partners to customers), and achieve vital security and compliance objectives.

Application access and user scenarios​

Enterprise Single Sign-On (SSO)​

Integrate with your organization's existing identity provider to provide seamless access:

{
  "name": "company-sso",
  "type": "OIDC",
  "config": {
    "clientId": "frontdoor-app-id",
    "clientSecret": "secure-client-secret",
    "issuerUrl": "https://auth.company.com",
    "scopes": ["openid", "email", "profile"]
  }
}

Use with email patterns to restrict access to employees: ["*@company.com"]

Partner and external access​

Provide secure access to external partners using their existing accounts:

{
  "name": "google-partners",
  "type": "GOOGLE",
  "config": {
    "clientId": "google-oauth-client-id",
    "clientSecret": "google-oauth-secret"
  }
}

Restrict access to specific partner domains: ["*@partner1.com", "*@partner2.com"]

Development team collaboration​

Enable development teams to access shared resources using GitHub accounts:

{
  "name": "github-developers",
  "type": "GITHUB",
  "config": {
    "clientId": "github-app-client-id",
    "clientSecret": "github-app-secret"
  }
}

Limit access to organization members: ["*@github.yourorg.com"]

Customer portal access​

Create customer-facing portals with Google OAuth for easy access:

{
  "name": "customer-portal",
  "type": "GOOGLE",
  "config": {
    "clientId": "customer-portal-client-id",
    "clientSecret": "customer-portal-secret"
  }
}

Allow access to specific customer domains or individual accounts.

Multi-tenant application access​

Support multiple customer organizations with their own identity providers:

  • Configure separate OIDC Auth Providers for each tenant
  • Use distinct email patterns for each organization
  • Create tenant-specific Shares with appropriate Auth Provider assignments

Compliance and audit requirements​

Implement OAuth authentication for regulatory compliance:

  • Use enterprise-grade identity providers with audit logging
  • Configure appropriate session timeouts for sensitive applications
  • Enable multi-factor authentication through OAuth provider settings
  • Implement email verification requirements

Certificate request tokens​

End user deployment​

Certificate request tokens provide certificates securely to end users without exposing sensitive API credentials. The token allows users to generate certificates by simply uploading a Certificate Signing Request (CSR), eliminating the need for direct API access. End users receive certificates signed by the certificate authority for their Frontdoor account while keeping their private keys secure on their own devices. This approach removes the complexity of managing API keys or credentials for certificate distribution scenarios.

Security considerations​

Token management​

Proper token management is critical for maintaining security throughout the certificate distribution process. Always share tokens through secure channels only, such as encrypted messaging systems or secure file transfers, to prevent interception by unauthorized parties. Remember that tokens are designed for single use and become invalid once redeemed for a certificate. Implement strict access control policies to ensure only authorized administrators can create tokens within your organization.

Certificate metadata​

Certificate metadata requires careful validation to maintain organizational security standards and consistency. Ensure all certificate metadata follows your organization's established standards for naming conventions and field population. Use consistent naming patterns for certificates that clearly indicate their purpose and environment. Populate organization fields accurately to maintain proper certificate identification, and always verify that Common Names match their intended use to prevent certificate misuse.

Client certificates​

API scurity​

Secure API endpoints by requiring client certificates:

# Client presents certificate when calling API
curl -X GET \
  --cert client.crt \
  --key client.key \
  https://api.example.com/v1/data

Microservices communication​

Enable service-to-service authentication:

  • Service A presents its certificate when calling Service B
  • Service B validates Service A's certificate before processing requests
  • No shared secrets or API keys needed

Compliance requirements​

Meet regulatory standards:

  • Financial services requiring strong authentication
  • Healthcare systems protecting patient data
  • Government systems with security clearance requirements

Zero trust architecture​

Implement "never trust, always verify" principles:

  • Every connection requires certificate validation
  • No implicit trust based on network location
  • Identity verification for all communication