Skip to main content
Identity Authority
Category: Cloud Identity

Federated Credential

Also known as: FIC, Federated Identity Credential, Federated Identity Credentials
Simply put

A federated credential is a way for one identity system to trust the authentication performed by another, so a user or software workload can gain access without a separate password or secret stored in the target system. Instead of managing its own login secret, the target relies on a trusted external identity provider to vouch for who is asking. This approach is often described as more secure and manageable because it removes the need to store and rotate long-lived secrets that could be leaked.

Formal definition

A federated credential establishes a trust relationship in which a resource or application accepts an identity assertion issued by an external, trusted identity provider rather than validating a locally held secret. In Microsoft Entra, federated identity credentials are described as a credential type that enables workload identity federation for software workloads, allowing a workload to obtain access using an externally issued token rather than a stored client secret or certificate. Note that the specific token formats, validation semantics, and trust configuration vary by platform and deployment; the evidence provided does not specify the underlying protocols or token structures, so those details are out of scope here. Conceptually this is a federation and authentication-trust mechanism, distinct from authorization decisions made once the federated identity is established.

Why it matters

The dominant risk that federated credentials address is the proliferation of long-lived secrets. When an application or workload authenticates using a stored client secret or certificate, that secret must be created, distributed, protected, rotated, and eventually revoked. Each of these steps is an opportunity for exposure, and a leaked secret can grant an attacker persistent access until someone notices and rotates it. By having a resource trust an assertion issued by an external identity provider rather than validating a locally held secret, a federated credential removes the need to store that long-lived secret in the target system at all.

This matters most acutely for machine-to-machine and workload scenarios. Sources describing Microsoft Entra workload identity federation frame federated identity credentials as a mechanism for software workloads to obtain access using an externally issued token instead of a stored secret, and one cited source specifically calls federated identity a more secure, scalable, and manageable authentication method for CI/CD pipelines such as Azure DevOps, noting that it removes the risk of leaked credentials. For teams operating many pipelines, service connections, or app registrations, eliminating hardcoded secrets reduces both attack surface and operational burden.

It is worth keeping the scope precise: a federated credential is an authentication-trust mechanism, establishing that the target will accept an assertion from a trusted external provider about who is asking. It does not by itself determine what the federated identity may do; authorization decisions are made separately once the identity is established. The evidence provided does not specify the underlying protocols, token formats, or validation semantics, and those vary by platform and deployment.

Who it's relevant to

IAM engineers and security architects
Those designing federation and workload identity patterns use federated credentials to eliminate stored client secrets and certificates from target systems, replacing them with trust in an external identity provider. They must define the trust relationship carefully, since the target will accept assertions from the configured provider, and confirm that authorization is handled as a separate concern once the federated identity is established.
DevOps and platform engineering teams
Teams running CI/CD pipelines are a primary audience, since federated identity is described as a more secure, scalable, and manageable authentication method for pipeline scenarios such as Azure DevOps, removing the risk of leaked credentials that hardcoded secrets introduce. This is especially relevant where many pipelines or service connections would otherwise each require a stored secret.
Cloud administrators working with Microsoft Entra
Administrators configuring workload identity federation in Entra encounter federated identity credentials (FIC) as a credential type that can be assigned directly to an App Registration instead of creating a separate stored secret. They are responsible for the trust configuration and should note that token formats and validation semantics vary by platform and deployment.
Compliance officers and auditors
Because federated credentials remove long-lived secrets that must be stored and rotated, they are relevant to reviewers assessing secret-management practices and credential exposure risk. Auditors should confirm how the external trust is configured and revoked, and remember that establishing a federated identity is distinct from the authorization controls that govern what that identity can access.

Inside FIC

Subject/Principal Identifier
A reference to the identity the credential represents, typically expressed as a subject claim (for example, the 'sub' claim in an OIDC ID token or a NameID in a SAML 2.0 assertion). The exact format and stability of this identifier depend on the federation protocol and provider configuration.
Issuer
The identity provider (IdP) or authorization server that authenticated the principal and asserted the credential. In OIDC this appears as the 'iss' claim; in SAML 2.0 it is conveyed in the assertion's Issuer element. The relying party validates that the issuer is a trusted federation partner.
Trust Relationship / Federation Metadata
The pre-established trust between the identity provider and the relying party (service provider), typically configured through exchanged metadata, signing keys, and endpoint information. This trust is what allows a credential issued by one domain to be accepted in another.
Signature and Cryptographic Material
Federated credentials are typically signed by the issuer so the relying party can verify integrity and origin, for example via XML Signature in SAML 2.0 or a JWS signature on a JWT-based token. Note that a signed credential is not necessarily encrypted; confidentiality requires separate encryption where needed.
Claims / Attributes
Assertions about the principal (such as identifiers, group or role attributes, and authentication context) carried in the credential. Depending on configuration, these may drive downstream authorization decisions, though the credential itself is primarily an authentication artifact.
Validity Constraints
Conditions bounding when and where the credential may be used, such as expiration/notation times, audience restrictions, and intended recipients. The specific constraints available depend on the protocol and profile in use.

Common questions

Answers to the questions practitioners most commonly ask about FIC.

Is a federated credential the same as a stored password kept in the identity provider?
No. A federated credential is not a synchronized or replicated password held at the relying party. In a federation, the user typically authenticates directly against their identity provider (IdP), and the relying party receives an assertion or token attesting to that authentication rather than the underlying secret. The relying party generally never sees or stores the user's primary credential. Depending on the protocol and profile in use (for example SAML 2.0 or OpenID Connect), what is exchanged is a signed statement about the authentication event, not the credential material itself.
Does using a federated credential mean OAuth 2.0 is authenticating the user?
Not on its own. OAuth 2.0 is a delegated authorization framework and does not, by itself, authenticate users. When a federated credential results in an authenticated user identity over an OAuth 2.0 substrate, that authentication is typically provided by OpenID Connect (OIDC Core), which is the authentication layer built on top of OAuth 2.0. In that flow, the ID token conveys authentication information about the user, while access tokens are used for authorization to resources. Treating a bare OAuth 2.0 access token as proof of user authentication is a common and incorrect assumption.
How is a federated credential validated at the relying party?
Validation depends on the protocol and profile. In most deployments, the relying party verifies the signature on the received assertion or token against the identity provider's published keys, and checks claims such as issuer, audience, and expiry, and where applicable nonce or subject binding. For SAML 2.0 this involves validating the signed XML assertion and its conditions; for OpenID Connect this involves validating the ID token's signature and standard claims. Note that a signed token establishes integrity and origin but is not necessarily encrypted, so confidentiality of claims depends on transport security or additional token encryption where configured.
How are federated identities provisioned into a relying party's directory?
Federation handles runtime authentication, but the corresponding account records are often provisioned separately. Many deployments use SCIM to provision, update, and deprovision user records at the relying party, keeping lifecycle state synchronized with the source of authority. Alternatively, some relying parties create accounts just-in-time on first successful federated sign-in, populating attributes from the incoming assertion. These are distinct concerns: provisioning and deprovisioning are identity governance and administration (IGA) functions, while validating the federated credential at sign-in is runtime enforcement.
How does a relying party map claims from a federated credential to local authorization?
Authentication via a federated credential establishes who the principal is; authorization is a separate step. Relying parties typically map incoming claims or attributes, such as subject identifiers, group memberships, or roles, to local access decisions. Depending on the access control model, those attributes may drive RBAC role assignment, feed ABAC or PBAC policy evaluation, or inform a policy decision point (PDP). Care is generally needed to consume only trusted, verified claims and to define how missing or unrecognized attributes are handled, since asserted claims reflect the identity provider's view and not necessarily the relying party's authorization intent.
What happens to sessions and access when a federated credential is revoked or the user is deactivated at the identity provider?
Revocation behavior varies by configuration. Deactivating a user or revoking a federated credential at the identity provider typically prevents future authentications, but already-issued tokens or established relying-party sessions may remain valid until they expire, depending on token lifetimes and whether session or token revocation mechanisms are in place. Some deployments shorten access token lifetimes, rely on refresh token revocation, or use back-channel logout or session-management features where the profile supports them. Coordinating identity provider deactivation with relying-party session termination and any SCIM-driven deprovisioning is generally required to close access promptly.

Common misconceptions

A federated credential grants the user access to the relying party's resources.
A federated credential is fundamentally an authentication artifact asserting who the principal is, along with attributes. Whether the principal may access a given resource is a separate authorization decision made by the relying party, which may use RBAC, ABAC, PBAC, or other models. Identification, authentication, and authorization remain distinct steps.
Because a federated credential is signed, its contents are protected from being read by intermediaries.
Signing provides integrity and proof of origin, not confidentiality. Unless the credential is also encrypted (for example, an encrypted SAML assertion or an encrypted JWT), its claims may be readable. Signing and encryption are separate protections.
Federation and the federated credential itself handle user provisioning at the relying party.
Runtime federation establishes trust and conveys authentication assertions at sign-in; it does not by itself manage account lifecycle. Provisioning, access reviews, and certification are typically handled by IGA processes, often using a separate mechanism such as SCIM, which operates independently of the runtime credential.

Best practices

Validate the issuer against your configured set of trusted federation partners and verify the credential's signature using the issuer's published keys before accepting any claims.
Enforce validity constraints such as expiration and audience/recipient restrictions so credentials cannot be replayed or presented to an unintended relying party.
Treat the credential as an authentication input only, and apply authorization decisions separately using your chosen access control model rather than assuming the credential's presence implies access.
Apply encryption in addition to signing when the credential carries sensitive claims, since signing alone does not provide confidentiality.
Keep runtime federation trust configuration current by regularly rotating and refreshing signing keys and metadata as supported by your providers.
Coordinate federated authentication with IGA lifecycle processes (for example, provisioning via SCIM and periodic access reviews) so account state and entitlements stay aligned with the identities being asserted.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps