Identity Providers

Identity Providers

Identity Providers

Connect your applications to external identity providers and enable Single Sign-On (SSO) across your organization. Skycloak simplifies the integration of popular identity providers like Google, Microsoft, GitHub, and enterprise systems like Active Directory and SAML providers.

Note: This page covers identity providers for your application’s end users. For team member authentication, see Workspace SSO.

Overview

Identity Providers in Skycloak enable you to:

  • Enable Single Sign-On (SSO) across all your applications
  • Connect social logins like Google, Facebook, and GitHub
  • Integrate enterprise identity with Azure AD, Okta, and Active Directory
  • Support SAML and OIDC protocols for maximum compatibility
  • Map user attributes from external sources
  • Link existing accounts automatically or manually
  • Configure conditional authentication based on identity source

Why Use Identity Providers?

For Your Users:

  • One password for everything (SSO)
  • Use existing accounts they trust
  • Faster registration and login
  • No more password fatigue

For Your Organization:

  • Centralized user management
  • Enhanced security with enterprise MFA
  • Reduced support tickets
  • Compliance with corporate policies
  • Simplified user provisioning

Prerequisites

  • An active Skycloak cluster
  • A configured realm
  • Admin permissions in your workspace
  • Credentials from your identity provider (Client ID, Secret, etc.)

Getting Started

Accessing Identity Providers

  1. Select your cluster and realm in the sidebar’s context stack
  2. Click Identity providers under the realm’s Connect section
  3. View configured providers or add new ones

The page lists your realm’s configured providers with status, and lets you add new ones from provider templates.

Trial realms ship with a built-in Sign in with Skycloak identity provider, added automatically so you and your team can log in to the realm with your Skycloak account from day one.

Quick Setup with Provider Templates

Using Provider Templates

Skycloak provides pre-configured templates for popular providers:

  1. Click “Add Provider”
  2. Choose your SSO provider from the gallery:
    • Popular Choices (Google, Microsoft, GitHub)
    • Enterprise SSO (Okta, OneLogin, JumpCloud, PingOne, and more)
    • Standard Protocols (OIDC, SAML 2.0)
  3. Configure on a single page — all settings are on one card

Choose Your SSO Provider gallery

Each card shows the provider’s logo, a one-line description, and its protocol (OIDC or SAML), so you can pick the right integration at a glance.

Express Setup Flow

After selecting a provider template, all configuration happens on a single page:

  1. Copy the Redirect URI shown at the top and paste it into your provider’s console
  2. Paste your credentials (Client ID & Secret for OIDC, Entity ID & SSO URL for SAML)
  3. Click “Test Connection” to verify your setup
  4. Click “Save & Enable” to activate the provider

For enterprise OIDC providers (Okta, Auth0, OneLogin, etc.), you can use OIDC Auto-Discovery: paste your provider’s discovery URL and click “Auto-Detect” to automatically populate all OAuth endpoints.

OAuth endpoints and step-by-step guides are available in collapsible sections if you need them.

Setting Up Google SSO

Step-by-Step Google Configuration

Let’s walk through setting up Google as an identity provider:

1. Create Google OAuth Application

First, set up your app in Google Cloud Console:

2. Configure in Skycloak

  1. Select the Google template from the provider gallery
  2. Copy the Redirect URI from the setup page and paste it into Google Cloud Console
  3. Enter your credentials:
    • Client ID from Google
    • Client Secret from Google
  4. Click “Test Connection” to verify
  5. Click “Save & Enable” to activate

OAuth endpoints are auto-filled for Google — no manual URL entry needed. If you want to review them, expand the “OAuth Endpoints” section.

Google provider configuration The Google express setup: paste your Client ID and Client Secret, copy the Redirect URI into Google Cloud Console, then test and enable — OAuth endpoints are pre-filled.

3. Advanced Settings

After saving, you can edit the provider to configure advanced settings:

  • Default Scopes: openid email profile
  • Store Tokens: Enable for token refresh
  • Trust Email: Enable if Google verifies emails
  • Sync Mode: Import users on first login
  • Link Accounts: Auto-link by email

Setting Up Azure AD (Microsoft)

Enterprise SSO with Azure Active Directory

Connect your Microsoft/Office 365 organization:

1. Register Application in Azure

  1. Go to Azure Portal > Azure Active Directory
  2. Register new application
  3. Configure redirect URIs
  4. Create client secret
  5. Note Tenant ID

2. Configure in Skycloak

  1. Select the Microsoft template from the provider gallery
  2. Copy the Redirect URI from the setup page into your Azure app registration
  3. Enter your credentials: Application (client) ID, Client Secret, and Tenant ID
  4. Click “Test Connection” to verify, then “Save & Enable” to activate

3. Attribute Mapping

Map Azure AD attributes to Keycloak:

  • given_namefirstName
  • family_namelastName
  • emailemail
  • groupsgroups (with transformation)

Setting Up SAML Providers

SAML Authentication Flows

SAML supports three authentication flows. Understanding which one you need helps configure your setup correctly.

Flow Who Starts It Configured In
SP-initiated Your application Skycloak SSO setup page
IdP-initiated Identity Provider portal Keycloak Admin Console + IdP
Proxy/Broker Keycloak as intermediary Keycloak Admin Console

Skycloak’s SSO setup page configures SP-initiated SSO — the most common flow where your application redirects users to the Identity Provider to authenticate. This is sufficient for most organizations.

If you need IdP-initiated SSO (users click an app tile in their Okta/Azure portal) or Proxy/Broker flows (multi-IdP federation), these require additional configuration in the Keycloak Admin Console. See the Enterprise SSO Setup Guide for detailed instructions.

SAML 2.0 Configuration

For enterprise SAML identity providers:

1. Basic SAML Setup

  1. Choose SAML 2.0 template

  2. Configure endpoints:

    • Single Sign-On URL
    • Single Logout URL (optional)
    • Metadata URL or upload file
  3. Upload or paste the signing certificate from your IdP

  4. Pick the NameID format your IdP sends (Email, Persistent, or Transient)

2. Advanced SAML Options

Security Settings:

  • Want AuthnRequests Signed
  • Want Assertions Signed
  • Want Assertions Encrypted
  • Force Authentication
  • Force POST Binding

Identity Provider Mappers

Customizing User Import

Transform and enrich user data during import:

Attribute Mappers

Map external attributes to Keycloak user properties:

  1. Create new mapper

  2. Select mapper type:

    • Attribute Importer
    • Hardcoded Attribute
    • Attribute Template
    • Role Importer
  3. Set the source claim and target user property, plus the sync mode (Import, Force, or Inherit)

Common Mapping Scenarios

Profile Enrichment:

External Claim → Keycloak Attribute
picture → profileImage
locale → preferredLanguage
department → customAttribute.department
manager → customAttribute.managerId

Role Mapping:

groups contains "admin" → realm role "administrator"
groups contains "developers" → client role "developer"

Account Linking

Linking Strategies

Control how external accounts link to existing users:

Automatic Linking:

  • By email (most common)
  • By username
  • Custom attribute matching

Manual Linking:

  • User initiates from account console
  • Admin links accounts
  • Verification required

First Login Flow

Configure what happens when users first login via identity provider:

  1. Review profile - Let users confirm/update imported data
  2. Verify email - If not verified by provider
  3. Set username - If not provided by provider
  4. Accept terms - Show terms of service
  5. Assign roles - Grant default permissions

Testing Identity Providers

Connection Testing

Verify your configuration works correctly:

  1. Click “Test Connection”
  2. Choose test method:
    • Quick test (verify endpoints)
    • Full test (complete login flow)
    • User test (specific account)

Multi-Provider Setup

Configuring Multiple Providers

Offer users choice of login methods:

Provider Priority:

  1. Set display order
  2. Configure default provider
  3. Hide providers per application
  4. Conditional display based on email domain

Provider Selection Strategies

Domain-based Routing:

  • @company.com → Azure AD
  • @gmail.com → Google
  • Others → Username/password

Home Realm Discovery:

  • Email input first
  • Auto-detect provider
  • Redirect accordingly

Security Best Practices

Provider Security

  1. Credential Management:

    • Store secrets securely
    • Rotate credentials regularly
    • Use environment-specific credentials
    • Never commit secrets to code
  2. Token Handling:

    • Validate all tokens
    • Check token expiration
    • Store tokens securely
    • Implement token refresh
  3. User Verification:

    • Verify email addresses
    • Check account status
    • Validate required attributes
    • Audit provider access

Account Security

Preventing Account Takeover:

  • Require email verification
  • Implement account linking confirmation
  • Monitor for suspicious linking patterns
  • Use risk-based authentication

Troubleshooting

Common Issues

“Invalid redirect URI” error:

  • Copy exact redirect URI from Skycloak
  • Add to provider’s allowed redirects
  • Check for trailing slashes
  • Verify HTTPS in production

Users not importing:

  • Check mapper configuration
  • Verify required scopes
  • Review provider permissions
  • Check first login flow

Attributes not syncing:

  • Verify claim names match
  • Check mapper syntax
  • Review scope permissions
  • Test with provider’s token debugger

Login loops:

  • Clear browser cookies
  • Check provider session settings
  • Verify redirect URI configuration
  • Review CORS settings

Supported Providers

Skycloak supports 33 identity providers out of the box, available on all plans. Providers are organized into categories for easy discovery.

Social & Developer Providers

Provider Protocol Best For
Google OIDC General apps, Google Workspace organizations
Microsoft OIDC Azure AD, Microsoft 365 organizations
GitHub OIDC Developer tools, open source projects
Facebook OIDC Consumer apps, social features
GitLab OIDC DevOps teams, self-hosted Git
Bitbucket OIDC Atlassian ecosystem, development teams
LinkedIn OIDC Professional networks, B2B apps
Slack OIDC Team collaboration, workspace apps
Discord OIDC Community platforms, gaming apps
Atlassian OIDC Jira/Confluence integrated apps
Twitch OIDC Streaming, gaming, entertainment apps
Stack Overflow OIDC Developer communities, technical Q&A platforms
PayPal OIDC Commerce applications, payment-linked identity

Enterprise OIDC Providers

Provider Protocol Best For
Okta OIDC Enterprise IAM, workforce identity
OneLogin OIDC Cloud identity management
JumpCloud OIDC Directory-as-a-Service, remote teams
PingOne OIDC PingIdentity cloud SSO
Auth0 OIDC Flexible authentication, developer-friendly
Salesforce OIDC CRM-integrated applications
Custom OIDC OIDC Any OpenID Connect 1.0 compliant provider

Enterprise SAML Providers

Provider Protocol Best For
Okta SAML Enterprise SAML federation
Azure AD SAML Microsoft enterprise environments
Google Workspace SAML Google-managed organizations
OneLogin SAML Cloud SAML integration
JumpCloud SAML Directory-based SAML
PingFederate SAML On-premise PingIdentity federation
PingOne SAML PingIdentity cloud SAML
Duo Security SAML Multi-factor authentication integration
Cloudflare Access SAML Zero Trust identity
CyberArk SAML Privileged access management
Custom SAML SAML Any SAML v2.0 compliant provider

Directory Services

Provider Protocol Best For
LDAP/AD LDAP Corporate directories, on-premise Active Directory
OpenShift OIDC Red Hat OpenShift-integrated applications

Provider-Specific Notes

GitHub:

  • Requires email scope explicitly
  • Organization membership available
  • Team synchronization possible

LinkedIn:

  • Uses OpenID Connect with profile and email scopes
  • Good for professional and B2B applications

Slack:

  • OAuth2-based (not full OIDC discovery)
  • Workspace-level authentication
  • Great for team collaboration tools

Discord:

  • OAuth2-based with identify and email scopes
  • Guild membership available for access control
  • Popular for community-driven applications

Okta:

  • Full OIDC and SAML compliance
  • Group synchronization
  • Custom attributes support

Auth0:

  • Universal login support
  • Custom database connections
  • Rules for transformation

Ping Identity (PingOne / PingFederate):

  • Enterprise federation
  • Both cloud (PingOne) and on-premise (PingFederate) options
  • Full SAML/OIDC support

Performance Considerations

Optimization Tips

  1. Cache provider metadata when possible
  2. Implement lazy loading for user attributes
  3. Use batch synchronization for large directories
  4. Configure appropriate timeouts
  5. Monitor provider API limits

Compliance and Privacy

Data Protection

GDPR Considerations:

  • Minimal data collection
  • User consent for data sharing
  • Right to deletion
  • Data portability

Audit Requirements:

  • Log all authentication events
  • Track provider access
  • Monitor data synchronization
  • Regular access reviews

Advanced Features

Conditional Authentication

Create dynamic authentication flows:

  • Require MFA for external users
  • Additional verification for new providers
  • Risk-based step-up authentication
  • Geographic restrictions

Identity Brokering

Chain multiple identity providers:

  • Organization IdP → Skycloak → Applications
  • Federated multi-organization access
  • Partner integration scenarios

Workspace SSO vs Realm Identity Providers

Understanding the difference:

Realm Identity Providers (This Page)

  • Purpose: Authentication for your application’s end users
  • Configured in: Individual realms within your clusters
  • Used by: Your customers/users accessing your applications
  • Example: Adding Google login to your customer-facing app

Workspace SSO

  • Purpose: Authentication for your team members
  • Configured in: Workspace security settings
  • Used by: Your team accessing Skycloak dashboard
  • Example: Team members using corporate Azure AD to access Skycloak
  • Available on: Enterprise plan only
  • Learn more: Workspace SSO Documentation

Related Features

Next Steps

Last updated on